Support deleting methods during precompilation for stdlib excision #51641
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Still fairly hacky and messy, but that's due to me not knowing this part of the code super well.
I originally was thinking I could scan all method tables and find deleted methods,
but I didn't find a way of expressing "these deletions are new".
I limited myself thusly to the part of the problem I need for #51432 and JuliaLang/LinearAlgebra.jl#1027,
in particular making my proposed delayed method trick compatible with caching,
by limiting the invalidation effect.
The problem with the
delete_methodin__init__approach is that we invalidate the method-table,after we have performed all of the caching work. A package dependent on
Random, will still seethe stub method in Base and thus when we delete the stub, we may invalidate useful work.
Instead we delete the methods when Random is being loaded, thus a dependent package only ever sees
the method table with all the methods in Random, and non of the stubs methods.
The only invalidation that thus may happen are calls to
randandrandnwithout first doing animport Random.