Sema: Allow protocols with 'Self' constraints again #19844
Merged
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
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
An extension might have an extended nominal, even if the extended type is an error type. This can happen if, for example, the type lookup was ambiguous, because the declaration lookup more eagerly disambiguates. This is fine, because even if we bind the extension to a nominal it's okay to diagnose an error later. However, we do have to deal with this case here by checking for an error type. A better solution would be to ensure the extended type is always set to something, even if we diagnosed an error while resolving it, because we can always use the declared type of the extended nominal instead. However when I tried that I ran into more problems, and I don't feel like shaving this yak right now.
Previously you could pass in a vector of TypeDecls and it handled module and AnyObject lookup for you. The AnyObject case was never used and the module was was only needed in one place, so clean things up to make them more direct here.
These two declarations are now equivalent:
protocol P : SomeClass { ... }
protocol P where Self : SomeClass { ... }
There's a long, complicated story here:
- Swift 4.2 rejected classes in the inheritance clause of a
protocol, but it accepted the 'where' clause form, even
though it didn't always work and would sometimes crash
- Recently we got the inheritance clause form working, and
added a diagnostic to ban the 'where' clause form, because
we thought it would simplify name lookup to not have to
consider the 'where' clause
- However, we already had to support looking at the 'where'
clause from name lookup anyway, because you could write
extension P where Self : SomeClass { ... }
- It turns out that despite the crashes, protocols with
'Self' constraints were already common enough that it was
worth supporting the existing behavior, instead of banning
it
Fixes <rdar://problem/43028442>.
slavapestov
force-pushed
the
protocol-where-self-is-crap
branch
from
495873f to
64f12ff
Compare
|
@swift-ci Please smoke test |
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.
This sort of worked in 4.2, then I banned it but it broke source comaptibility.
Now that protocol superclass constraints are fully supported, let's allow this again, with some minor refactoring to the request evaluator.
So both of these are equivalent and should work correctly:
Fixes rdar://problem/43028442.