[DiagnosticsQoI] Strike VarDecls in Pattern Binding Initializers From Overloads #27668
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
We would previously consider the VarDecls bound by a particular pattern
binding initializer context when performing overload resolution. This
would lead to circular validation. Validation was tacitly breaking the
cycle by returning an error type (but, crucially, not setting that
interface type). Instead, pre-reject circular candidates.
This greatly improves the diagnostic we emit here in truly circular
cases since we can ride on `UR_InstanceMemberOnType` to yield
struct PatternBindingWithTwoVars2 { var x = y, y = 3 }
// cannot use instance member 'y' within property initializer; property initializers run before 'self' is available
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
xedin
approved these changes
Oct 14, 2019
|
There's that old UPASS... ⛵️ |
CodaFi
added a commit
to CodaFi/swift
that referenced
this pull request
Oct 16, 2019
Extend swiftlang#27668 by declining to validate the type of variables bound by a pattern binding initializer when computing an effective overload type while rooted at that initializer.
CodaFi
added a commit
to CodaFi/swift
that referenced
this pull request
Oct 21, 2019
Resolve a cycle caused by overload resolution considering recursive static candidates where before it would silently reject them. In a world before the InterfaceTypeRequest, the overload resolution machinery would attempt to validate the declaration and would recieve a bad answer. This caused circular candidates to be ignored as a side effect. This behavior was partially restored by the fixes in swiftlang#27725 and swiftlang#27668 but that isn't enough for recursive static variables. Even if it were, the constraint fix kind doesn't make sense. Luckily, the right answer is to just reject recursive static VarDecl candidates entirely. Addresses rdar://56410015
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.
We would previously consider the VarDecls bound by a particular pattern
binding initializer context when performing overload resolution. This
would lead to circular validation. Validation was tacitly breaking the
cycle by returning an error type (but, crucially, not setting that
interface type). Instead, pre-reject circular candidates.
This greatly improves the diagnostic we emit here in truly circular
cases since we can ride on
UR_InstanceMemberOnTypeto yield