[5.0] [Name lookup] Enable shadowing for type lookup and of the Swift module. #21378
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
… rather than co-opting NULL, which is a valid CanType type.
Tweak the shadowing rules in two ways: 1) For unqualified type lookup, apply shadowing rules. Without this, we would always get an ambiguity if there were two types with the same name, so this should be a strict improvement. 2) Allow a name introduced in any other module to shadow a name in the Swift standard library. This is (another) weak form of a more sensible, generalized rule that would use the import graph to describe shadowing. Together, these tweaks allow the Result type that was recently introduced in the standard library to exist without breaking source compatibility for Swift code that is already using a Result type. The user Result type will shadow (hide) the Swift one. The latter can be spelled Swift.Result if it is needed by such code. Fixes rdar://problem/46767892.
We’re going to need to use this in GenericSignature.cpp. NFC
Narrow the recently-introduced shadowing rule for types so that it only applies to non-member types. Member types lack a reasonable syntax for specifying precisely which module to look into, and there are a few use cases where the type checker will pick a type that would be shadowed by the new rule. Fixes a source-compatibility regression introduced by the shadowing rule.
When substituting type parameters to compute a canonical type within a given generic context, also handle the case where the type parameter is directly known to be a concrete type. The type checker won’t do this, but SourceKit does. Fixes a regression in SourceKit/DocSupport/doc_stdlib.swift.
|
Note that this only makes sense to test on top of #21225 |
|
@swift-ci please test |
AnnaZaks
approved these changes
Dec 17, 2018
|
Build failed |
|
@swift-ci please test Linux |
|
Huh. It almost looks like SwiftPM isn't picking up a newer Swift, because it's failing with the ambiguity that this change fixes. |
|
Build failed |
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.
Tweak the shadowing rules in two ways:
would always get an ambiguity if there were two types with the same name,
so this should be a strict improvement.
Swift standard library. This is (another) weak form of a more sensible,
generalized rule that would use the import graph to describe shadowing.
Together, these tweaks allow the Result type that was recently introduced in
the standard library to exist without breaking source compatibility for
Swift code that is already using a Result type. The user Result type will
shadow (hide) the Swift one. The latter can be spelled Swift.Result if it
is needed by such code.