Only implicitly using Base, not Core
#57357
Merged
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
|
Looks excellent! Thanks Does this mean you now need |
|
No, I added Core to Base's export set along with the other |
lgoettgens
reviewed
Feb 11, 2025
|
Hmm, looks like this impacted type-alias printing somehow.
ref::MemoryRef{T}turned into ref::GenericMemoryRef{:not_atomic, T, Core.AddrSpace{Core}(0x00)} |
Keno
force-pushed
the
kf/usingbaseonly
branch
2 times, most recently
from
e0dfb14 to
d356074
Compare
vtjnash
reviewed
Feb 12, 2025
src/toplevel.c
Outdated
Comment on lines
138
to
139
| // If we have `Base`, don't also try to import `Core` - the `Base` exports are a superset and we | ||
| // avoid ambiguities as to which module the bindings should come from. |
There was a problem hiding this comment.
Suggested change
| // If we have `Base`, don't also try to import `Core` - the `Base` exports are a superset and we | |
| // avoid ambiguities as to which module the bindings should come from. | |
| // If we have `Base`, don't also try to import `Core` - the `Base` exports are a superset |
This statement does not seem consistent with the definition of exports, since something cannot be ambiguous if it has the same value.
There was a problem hiding this comment.
The binding isn't ambiguous, but it's ambiguous where the binding came from, which we print in various places and people complain.
There was a problem hiding this comment.
Ah, might help to update the wording then to be clear that the ambiguity is just the printing of the module name, not the value?
Inspired by the question in #57311 (comment), I want to revisit the basic setup where every module `using`s both `Core` and `Base`. In general, I think we mostly expect users to inferface with `Base`, not `Core`, so this PR changes things to only have new modules `using` Base (while re-exporting all `Core` names from `Base`). There should be little user-visible impact from these changes. The only situation I can think of where it makes a difference is if somebody were to make their own Base/toplevel module that does not re-export Core. However, we don't really support that situation in the first place, and I actually think it's a feature that such toplevel modules can more closely control the set of implicitly exposed names.
Keno
force-pushed
the
kf/usingbaseonly
branch
from
d356074 to
7059570
Compare
KristofferC
pushed a commit
that referenced
this pull request
Feb 14, 2025
Inspired by the question in #57311 (comment), I want to revisit the basic setup where every module `using`s both `Core` and `Base`. In general, I think we mostly expect users to inferface with `Base`, not `Core`, so this PR changes things to only have new modules `using` Base (while re-exporting all `Core` names from `Base`). There should be little user-visible impact from these changes. The only situation I can think of where it makes a difference is if somebody were to make their own Base/toplevel module that does not re-export Core. However, we don't really support that situation in the first place, and I actually think it's a feature that such toplevel modules can more closely control the set of implicitly exposed names. (cherry picked from commit 20162ea)
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
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.
Inspired by the question in #57311 (comment), I want to revisit the basic setup where every module
usings bothCoreandBase. In general, I think we mostly expect users to inferface withBase, notCore, so this PR changes things to only have new modulesusingBase (while re-exporting allCorenames fromBase). There should be little user-visible impact from these changes. The only situation I can think of where it makes a difference is if somebody were to make their own Base/toplevel module that does not re-export Core. However, we don't really support that situation in the first place, and I actually think it's a feature that such toplevel modules can more closely control the set of implicitly exposed names.