SE-0036 (2/3): Provide warnings when referencing enum elements on instances #2842
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.
What's in this pull request?
This is part 2/3 implementing SE-0036:
This provides warnings when referencing an enum element on an instance together with a single-dot fix-it for
case
statements and a fully qualified name fix-it everywhere else.Dependencies
I wasn’t sure how I should handle the multi-staged rollout of SE-0036 as described here. So this PR includes the changes to the test cases that shall be merged in #2841 and builds on top of them, i.e. the branch for this PR is one commit ahead of the one for #2841. I hope that’s the right way to go, otherwise let me know.
Note to those familiar with the old error-based implementation in #2634
The detection in the warning-bases approach is completely different to the one used when errors were generated. As a result, I wasn’t able to provide the same fix-its. Especially I can no longer determine that a single dot suffices if the type could be inferred based on the constraint system's
contextType
, e.g. inself = .A
. As you can see in the updated tests in #2841, almost all migration help seems to be about migratingcase
statements, however. So I believe that it’s not that big a deal if in these cases a fully qualified type is suggested.Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.