RFC: remove deprecation about __precompile__(true) #28459
Conversation
StefanKarpinski
added
kind:deprecation
base/loading.jl
Outdated
| if isprecompilable | ||
| depwarn("__precompile__() is now the default", :__precompile__) | ||
| elseif 0 != ccall(:jl_generating_output, Cint, ()) | ||
| if ccall(:jl_generating_output, Cint, ()) != 0 |
There was a problem hiding this comment.
&& !isprecompilable ?
base/loading.jl
Outdated
|
|
||
| Specify that the file calling this function is not precompilable. | ||
| Specify that the file calling this function is not precompilable, defaulting to `true`. |
There was a problem hiding this comment.
The wording makes it sound like precompilation is disabled by default. I'd reword as
Specify whether the file calling this function is precompilable, defaulting to
true. If this function is not called explicitly, precompilation will be enabled by default.
|
Updated. |
KristofferC
force-pushed
the
kc/precompile_dep
branch
from
70b72c4
to
4fea09e
Compare
KristofferC
force-pushed
the
kc/precompile_dep
branch
from
4fea09e
to
b55d5f5
Compare
|
Yeah, that's a good point. |
|
Thinking about this more, isn't the deprecation message fine to have for 0.7? It will tell people what the behavior will be in 1.0 before we silently break it. |
|
That would be a different message though --- in the case where there's no |
|
I see. It seems definitely worthwhile to me to emit a warning when there's no |
|
Separate PR? :) |
|
Yeah definitely |
I don't think we should do this. It's perfectly legal to have no precompile call now and the previous depwarn has caused people to remove theirs. |
Yeah, the deprecation should have deprecated having no precompile statement forcing people to do |
|
Agreed. I also think most/all packages that don't support precompilation have already marked |
(cherry picked from commit e3bc48d)
(cherry picked from commit e3bc48d)
Doesn't seem to be much value in deprecating this?