In #20 I gave control to the user in which module they use for resolving symbols inside the RGF.

But I've now realized this could lead to precompilation issues if the user specifies a module for symbol resolution which is not the current module. As noted in https://github.com/SciML/ModelingToolkit.jl/pull/681#issuecomment-738752271, there's actually two things that might be required separately:

Ability to specify which module's precompile cache the RGF lives in.
Ability to specify which module is used to look up global symbols used in that RGF (including generic functions)

20 provides the second of these, but ignores the first. That makes it safe to use at runtime, but precompilation may be broken if the user uses a third party module.

I wonder what the best API is here for constructing RGFs. Perhaps we could provide:

# Use `mod` for both the cache and for lookup
RuntimeGeneratedFunction(mod, code)

# Use `mod` for symbol lookup, and `mod2` for precompilation cache
RuntimeGeneratedFunction(mod, code, precompile_in=mod2)

Alternatively we could decide we always want precompile_in=@__MODULE__ (this guarantees users won't have precompilation issues), and bring back the macro after all:

# resolve symbols in `mod`
@RuntimeGeneratedFunction(mod, code)

# resolve symbols in current module
@RuntimeGeneratedFunction(code)

Supporting different mod1 and mod2 would require an additional type parameter.

I guess I slightly favor the latter, so maybe we should revert #20. Thoughts?

SciML / RuntimeGeneratedFunctions.jl

Modules for caching RGF ASTs vs resolving global symbols #21

20 provides the second of these, but ignores the first. That makes it safe to use at runtime, but precompilation may be broken if the user uses a third party module.