Provide an interface to "hook" into the symbol and/or type resolution

[oxisto]

In a certain use-case where we want to analyze some dynamic aspects of a python program, we are in the need to replicate the behavior of dynamically loading a class at runtime (depending on a config option), or more specifically we want to influence the type of a variable (or the return type of a function depending on the analysis). Now the tricky part is that in order for the rest to work, we need to do that either before the symbol resolver runs or maybe during symbol resolving, so that we can at least have partially resolved symbols. If we then for example make sure that our application code depends on the config, we might have a chance that the config symbol is already resolved.

To demonstrate, take the following Python pseudo-code.

real_class_str = config.my_class_as_str # this is actually fetched from a ini file or similar

cls = some_manager.Load(real_class_str, some_option=True)

In the above case, we want to set the return type of Load or the type of class to a specific class that is in the config.

The issue is that this is not really a feature of the language, but rather implemented by various libraries and we want to keep modeling the framework-specific stuff out of the language frontend. Maybe we can create a concept for that, but even the concepts are not available in cpg-core.

Therefore, we need some kind of agnostic interface in the symbol resolver that we can magically hook from the "outside", e.g., exposed through a PassConfiguration.

[oxisto]

On second thought I wonder, whether just "replacing" the symbol resolver with an overwritten (and extended) symbol resolver will be enough to realize this.