bpart: Also partition the export flag #57405
Merged
+181
−110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keno
force-pushed
the
kf/partitionexport
branch
from
208b7df to
b9b8266
Compare
Whether or not a binding is exported affects the binding resolution of any downstream modules that `using` the module that defines the binding. As such, it needs to fully participate in the invalidation mechanism, so that code which references bindings whose resolution may have changed get properly invalidated. To do this, move the `exportp` flag from Binding into a separate bitflag set that gets or'd into the BindingPartition `->kind` field. Note that we do not move `publicp` in the same way since it does not affect binding resolution. There is currently no mechanism to un-export a binding, although the system is set up to support this in the future (and Revise may want it). That said, at such a time, we may need to revisit the above decision on `publicp`. Lastly, I will note that this adds a fair number of additional invalidations. Most of these are unnecessary, as changing an export only affects the *downstream* users not the binding itself. I am planning to tackle this as part of a larger future PR that avoids invalidation when this is not required. Fixes #57377
Keno
force-pushed
the
kf/partitionexport
branch
from
b9b8266 to
b53d541
Compare
Keno
added a commit
that referenced
this pull request
Feb 15, 2025
This makes non-guard bindings stronger than guard bindings for ambiguity purposes. Note that both of these are yet stronger than deprecated bindings, so if there's a "non-guard deprecated" binding and a "guard non-deprecated" binding, the latter will win and the access will be UndefVarError. I think this is the closest to the 1.11 behavior without relying on resolvedness. Fixes #57404 This PR is against #57405 just because that PR touches the common interface, but is conceptually independent.
KristofferC
pushed a commit
that referenced
this pull request
Feb 15, 2025
Whether or not a binding is exported affects the binding resolution of any downstream modules that `using` the module that defines the binding. As such, it needs to fully participate in the invalidation mechanism, so that code which references bindings whose resolution may have changed get properly invalidated. To do this, move the `exportp` flag from Binding into a separate bitflag set that gets or'd into the BindingPartition `->kind` field. Note that we do not move `publicp` in the same way since it does not affect binding resolution. There is currently no mechanism to un-export a binding, although the system is set up to support this in the future (and Revise may want it). That said, at such a time, we may need to revisit the above decision on `publicp`. Lastly, I will note that this adds a fair number of additional invalidations. Most of these are unnecessary, as changing an export only affects the *downstream* users not the binding itself. I am planning to tackle this as part of a larger future PR that avoids invalidation when this is not required. Fixes #57377 (cherry picked from commit b27a24a)
KristofferC
pushed a commit
that referenced
this pull request
Feb 15, 2025
This makes non-guard bindings stronger than guard bindings for ambiguity purposes. Note that both of these are yet stronger than deprecated bindings, so if there's a "non-guard deprecated" binding and a "guard non-deprecated" binding, the latter will win and the access will be UndefVarError. I think this is the closest to the 1.11 behavior without relying on resolvedness. Fixes #57404 This PR is against #57405 just because that PR touches the common interface, but is conceptually independent. (cherry picked from commit a371899)
KristofferC
added a commit
that referenced
this pull request
Feb 17, 2025
Backported PRs: - [x] #57346 <!-- lowering: Only try to define the method once --> - [x] #57341 <!-- bpart: When backdating replace the entire bpart chain --> - [x] #57381 <!-- staticdata: Set min validation world to require world --> - [x] #57357 <!-- Only implicitly `using` Base, not Core --> - [x] #57383 <!-- staticdata: Fix typo in recursive edge revalidation --> - [x] #57385 <!-- bpart: Move kind enum into its intended place --> - [x] #57275 <!-- Compiler: fix unsoundness of getfield_tfunc on Tuple Types --> - [x] #57378 <!-- print admonition for auto-import only once per module --> - [x] #57392 <!-- [LateLowerGCFrame] fix PlaceGCFrameReset for returns_twice --> - [x] #57388 <!-- Bump JuliaSyntax to v1.0.2 --> - [x] #57266 <!-- 🤖 [master] Bump the Statistics stdlib from d49c2bf to 77bd570 --> - [x] #57395 <!-- lowering: fix has_fcall computation --> - [x] #57204 <!-- Clarify mathematical definition of `gcd` --> - [x] #56794 <!-- Make `Pairs` public --> - [x] #57407 <!-- staticdata: corrected implementation of jl_collect_new_roots --> - [x] #57405 <!-- bpart: Also partition the export flag --> - [x] #57420 <!-- Compiler: Fix check for IRShow definedness --> - [x] #55875 <!-- fix `(-Inf)^-1` inconsistency --> - [x] #57317 <!-- internals: add _defaultctor function for defining ctors --> - [x] #57406 <!-- bpart: Ignore guard bindings for ambiguity purposes --> - [x] #49933 <!-- Allow for :foreigncall to transition to GC safe automatically -->
KristofferC
removed
the
backport 1.12
Keno
added a commit
that referenced
this pull request
Feb 18, 2025
This repeats the exercise in #57405. This is required for correctness, because the ->deprecated flag also affects `using` resolution (since it makes the tagged binding weaker for `using` purposes). That said, in general our `->deprecated` semantics have been somewhat underspecified with lots of `XXX` comments in the surrounding code. This tries to define the semantics to give a depwarn on *access* (read or write) when: 1. Either the binding itself is deprecated; or 2. The implicit imports pass through a deprecated binding. However, we do not give depwarns on access to bindings that were explicitly imported (although we do give those warnings on the import) - the reasoning being that it's the import that needs to be adjusted not the access. Additionally, this PR moves into the direction of making the depwarn a semantic part of the global access, by adjusting codegen and inference appropriately.
Keno
added a commit
that referenced
this pull request
Feb 18, 2025
This repeats the exercise in #57405. This is required for correctness, because the ->deprecated flag also affects `using` resolution (since it makes the tagged binding weaker for `using` purposes). That said, in general our `->deprecated` semantics have been somewhat underspecified with lots of `XXX` comments in the surrounding code. This tries to define the semantics to give a depwarn on *access* (read or write) when: 1. Either the binding itself is deprecated; or 2. The implicit imports pass through a deprecated binding. However, we do not give depwarns on access to bindings that were explicitly imported (although we do give those warnings on the import) - the reasoning being that it's the import that needs to be adjusted not the access. Additionally, this PR moves into the direction of making the depwarn a semantic part of the global access, by adjusting codegen and inference appropriately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Whether or not a binding is exported affects the binding resolution of any downstream modules that
usingthe module that defines the binding. As such, it needs to fully participate in the invalidation mechanism, so that code which references bindings whose resolution may have changed get properly invalidated.To do this, move the
exportpflag from Binding into a separate bitflag set that gets or'd into the BindingPartition->kindfield. Note that we do not movepublicpin the same way since it does not affect binding resolution.There is currently no mechanism to un-export a binding, although the system is set up to support this in the future (and Revise may want it). That said, at such a time, we may need to revisit the above decision on
publicp.Lastly, I will note that this adds a fair number of additional invalidations. Most of these are unnecessary, as changing an export only affects the downstream users not the binding itself. I am planning to tackle this as part of a larger future PR that avoids invalidation when this is not required.
Fixes #57377