[SE-0491] Implement experimental module selectors (MyMod::someName) #34556
+3,342
−524
Conversation
This file contains hidden or 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
beccadax
changed the title
beccadax
force-pushed
the
mod-squad-2
branch
3 times, most recently
from
eb8ecdf to
b6d41f6
Compare
beccadax
commented
Jul 21, 2021
beccadax
force-pushed
the
mod-squad-2
branch
3 times, most recently
from
9c9e8e9 to
6edf769
Compare
beccadax
requested review from
AnthonyLatsis,
CodaFi,
DougGregor,
ahoppen,
bnbarham,
hamishknight,
hborla,
rintaro,
slavapestov,
xedin and
xymus
as code owners
|
Woohoo! Thank you for reviving this, Becca! |
A PatternBindingEntry formed from a MissingPatternSyntax has no valid SourceLocs in it, and a PatternBindingDecl containing only PatternBindingEntries with no valid SourceLocs trips an assertion during availability checking. (Generating dummy SourceLocs can cause invalid overlaps between AvailabilityScopes, so that’s not a workable solution.) The fix is to: • Refuse to generate a PatternBindingEntry from a PatternBindingSyntax with a MissingPatternSyntax (MissingPatternSyntaxes at nested positions don’t have this problem) • Refuse to generate a PatternBindingDecl with no PatternBindingEntries This ensures that the invalid AST nodes are never formed. No current test cases hit this problem, but certain invalid module selector tests can run into this situation when run with ASTGen.
|
@swift-ci build toolchain macOS platform |
beccadax
changed the title
The `_Concurrency` and `_StringProcessing` modules are implementation details of the standard library; to developers, their contents should behave as though they are declared directly within module `Swift`. This is the exact same behavior we expect of cross-import overlays, so treat these modules as though they are cross-import overlays with no bystanding module. Because these modules don’t re-export the standard library, it’s also necessary to treat `Swift` as a separately imported overlay of itself; do so and make that actually work.
The diagnostics in this test will evolve as we implement pieces of the feature.
In this commit, this change affects certain diagnostics but doesn’t actually alter name lookup behavior yet.
Adds comments explaining why these conversions aren’t lossy.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
beccadax
force-pushed
the
mod-squad-2
branch
from
095cc51 to
736e878
Compare
This support is currently opt-in and has several modes.
Requires tests.
• A module selector which specifies module `Foo` will also select declarations in cross-import overlays declared by `Foo`. • Module selector-related diagnostics for a declaration in a cross-import overlay will recommend naming the declaring module in the module selector (taking advantage of the above). The overall effect is to preserve the illusion that declarations in cross-import overlays belong to the declaring module. This also applies to the standard library’s separately-imported overlays.
In code like the following:
```
protocol P { associatedtype A: Hashable }
protocol Q { associatedtype A: Comparable }
func fn<T: P & Q>(_: T) where T.A == Int { … }
```
`T.A` is actually the union of `P.A` and `Q.A`—it satisfies both associated types and has both of their constraints. This means it doesn’t actually make sense to apply a module selector to `A`—even if `P` and `Q` are in different modules, `T.A` always represents both of the declarations, not one or the other. We therefore now ban module selectors in this position, since they don’t actually jibe with the nature of a generic signature.
This justification technically doesn’t hold for *every* member type of a generic parameter—a member type can refer to a concrete typealias in a protocol extension, for instance—but in those situations, you can disambiguate (and add module selectors) by writing `P.A` or `Q.A` instead of `T.A`, so we’re not really worried about this limitation.
beccadax
force-pushed
the
mod-squad-2
branch
from
736e878 to
303480e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This pull request begins to implement "module selectors", which allow references to declarations to be unambiguously prefixed with a module they can be found through:
This PR parses module selectors and partially implements lookup and diagnostics for them. The new functionality is hidden behind an
-enable-experimental-module-selectorfrontend flag. There is one diagnostic regression with that flag enabled, but I've made sure that it keeps working when the diagnostic is disabled.This work was previously in PR #28834, which was closed during the master-to-main transition. I've updated it to work on modern compilers, including removing some FIXMEs for bad diagnostics that have improved since December 2019.
Makes progress on rdar://problem/19481048.