SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations (once again)

[ahoppen]

What's in this pull request?

This is a follow up to #2224, which has been merged and reversed, implementing SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

I added the following fix-its to the original PR:

• Fix-it using . where the type can be inferred using the constraint system’s contextual type, e.g. self = A to self = .A
• Fix-it using . in case statements of non-generic enum elements
• Fix-it using the fully specified type without generic parameters everywhere else. Generic parameters could be inferred in all examples I could think of.

The generation of the fix-it for case statements is, for my taste, quite ugly as it directly references the ~= pattern matching operator and its arguments. But it was the best solution I could think of without rerunning the constraint system on a modified copy of the AST, where a . has been added as a guess.

Thus, I would suggest removing the fix-it once the transition to Swift 3 has been finished, for example in the Swift 4 timeframe. I guess it provides little benefit apart from automated transitioning anyway.

Resolved bug number: (SR-1236)

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

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

Platform	Comment
All supported platforms	@swift-ci Please smoke test
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
OS X platform	@swift-ci Please test OS X platform
Linux platform	@swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

[DougGregor]

The implementation is looking good, but I'd like us to stage things a bit more softly via warnings + Fix-Its, and we'll wait until some time later before making this a hard error. First of all, all of the test suite changes that merely change to the always-permitted-but-now-required qualified syntax can just go in, so you won't need to carry that change set around. Second, instead of changing name lookup and breaking existing programs, I propose that we detect when an unqualified reference is referring to an enum case, produce a warning with Fix-Its (which you have great logic for), but allow the code to compile. That will help developers move forward with this change without unnecessary breakage.

[ahoppen]

I created three PRs, each referencing a further state in the deployment of SE-0036:

• SE-0036 (1/3): Update existing tests for the upcoming implementation #2841 updates the existing tests to comply with the new syntax (and is fully backwards compatible)
• SE-0036 (2/3): Provide warnings when referencing enum elements on instances #2842 adds warnings when looking up enum elements on instances (using a completely different logic than has been implemented for this PR)
• SE-0036 (3/3): Provide errors when referencing enum elements on instances #2843 removes the warnings and adds the code that was already present in this PR, resulting in the same state