-
-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Description
Consider a package like:
module DroppedPrecompile
using PrecompileTools
macro fancy_macro()
f = Core.compilerbarrier(:type, length)
return f(Tuple{Int64,Int32,Int16,Int8}[]) # this does not end up pre-compiled
end
@compile_workload begin
@fancy_macro
end
end # module DroppedPrecompileThe dynamically called Base.length(::Tuple{Int64,Int32,Int16,Int8}) does not end up pre-compiled:
julia> using DroppedPrecompile
julia> Base.method_instance(Base.length, (Vector{Tuple{Int64,Int32,Int16,Int8}},)).cache
ERROR: UndefRefError: access to undefined referenceLogically, this makes sense - the macro expansion happens before the begin ... end block actually starts to execute.
Nonetheless, I wanted to file an issue, since it is a practical issue for libraries like ModelingToolkit.jl, which hit this use case (https://github.com/SciML/ModelingToolkit.jl/blob/3f965be3d256412844f7d43262d75fb48657c2df/src/ModelingToolkit.jl#L245-L278) and probably do intend to pre-compile the macros themselves, so that these are fast for future users.
Is there any good option for MTK to "opt-in" to including macro expansion in the workload?
Metadata
Metadata
Assignees
Labels
No labels