Fix some invalidations from extending ==(::SomeType, ::Any)
#36255
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.
I spent some time investigating #36005 as a way of exercising the new tools that I'm in the process of releasing. This PR, plus some unsubmitted fixes to JuliaInterpreter, LoweredCodeUtils, and Revise (which were loaded when the tests below were run) fixes more than 1000 invalidations, but some of the trickier ones remain to be addressed.
First, let's see where we started:
So, all invalidations stem from these two methods. Methods like that show up fairly frequently, so this is not an atypical case.
This PR (and the ones in JuliaInterpreter etc) focus on the big culprit,
==(::Any, ::Symbol)
, reducing the total number of children from 1764 to 93. So, major progress.It does not, however, fix the issue mentioned in #36005. That turns out to be a consequence of invalidating
Base.require(::Module, ::Symbol)
. You can see the call chain that leads here like this (requires the just-tagged SnoopCompile 1.4):(To clarify, this is just one "path" stemming from
==(::Symbol, ::Any)
, accounting for 16 of the 327 children. It's just the path that first reachesrequire
.)Lots of similar invalidations pass through
ht_keyindex
andht_keyindex2
. Anything that uses aDict{Any,K}()
and then uses aSymbol
as a key is vulnerable to this. I am not quite sure how to fix this, if we indeed want to fix it. Here are some options:==
andisequal
for certain types. One would define a trait and dispatch hierarchy that declares that==(::Any, ::Symbol)
and==(::Symbol, ::Any)
always pass through===
without the possibility of calling==
.My favorite is option 3, followed by 1. Option 2 makes me think "yuck."