-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix --compile=all
option, and some improvements for --strip-ir
#46935
Conversation
{ | ||
jl_array_t *found = (jl_array_t*)env; | ||
// method definition -- compile template field | ||
jl_array_t *allmeths = (jl_array_t*)env; | ||
jl_method_t *m = ml->func.method; | ||
if (m->source) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we try to normalize on whether !source
or source == jl_nothing
implies the absence of source code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sounds like a good idea.
It could, what would be a good test? Just compile a new sysimage with |
0dfdf23
to
e2d043e
Compare
e2d043e
to
1f0c2e2
Compare
--compile=all
has been broken for several releases. What it's supposed to do is simply compile one generic implementation (i.e. specialized for the declared argument types of a method) for each method, so that programs can run without the compiler or IR present.Fixes calling
return_type
in images built with --strip-ir; we were just missing anothing
check.Also don't bother compiling code for the type inference world when using --strip-ir.(Left this out for now in the interest of minimizing disruption.) It would be good to be able to exclude Core.Compiler entirely in that case, but it's not trivial due toreturn_type
.Also make
--compile
and module-level settings take precedence overforce_compile
metadata.Obviously, this could use tests --- maybe it can be tested as part of PackageCompiler?
Possible future work: remove the Method.unspecialized field, since all it does is cache the lookup of one specialization, but that lookup should only be done in slow paths.