Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-14408] Improve diagnostic when trying to use enum case without payload #56765

Closed
typesanitizer opened this issue Mar 27, 2021 · 5 comments
Closed

Comments

@typesanitizer
Copy link

@typesanitizer typesanitizer commented Mar 27, 2021

Previous ID SR-14408
Radar rdar://17718836
Original Reporter @typesanitizer
Type Improvement
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: 34e58d22ee98f59e77c57a4b3543f250

is duplicated by:

  • SR-14428 Comparing enum with associated value gives misleading error about unrelated enum

Issue Description:

enum CompassPoint {
    case North(Int)
    case South
    case East
    case West
}

func isNorth(c : CompassPoint) -> Bool {
  return c == .North
// error: binary operator '==' cannot be applied to operands of type 'CompassPoint' and '_' return c == .North
// error: cannot infer contextual base in reference to member 'North' 
}

func isSouth(c : CompassPoint) -> Bool {
  return c == .South
// error: binary operator '==' cannot be applied to two 'CompassPoint' operands
// note: binary operator '==' cannot be synthesized for enums with associated values 
}

Notice that the diagnostic is better for the c == .South case. It would be nice if the type-checker could recognize that in the c == .North case, the user was trying to access CompassPoint.North and emit a more useful diagnostic.

@typesanitizer
Copy link
Author

@typesanitizer typesanitizer commented Mar 27, 2021

cc luciano (JIRA User), potentially of interest to you since you often end up tackling these kinds of diagnostic improvements. 🙂

@LucianoPAlmeida
Copy link
Collaborator

@LucianoPAlmeida LucianoPAlmeida commented Mar 27, 2021

Interested! Thanks for the ping theindigamer (JIRA User) =]
I think this is somewhat related to SR-12908, not exactly sure is a dupe but I think they are similar

@typesanitizer
Copy link
Author

@typesanitizer typesanitizer commented Mar 29, 2021

Good spot, they are quite similar. There's a slight difference in that, in this case, CompassPoint doesn't have an Equatable conformance, whereas in the latter case, Result does have a conditional conformance but that is not used because TwoValues does not have an Equatable conformance.

I don't know if that makes this one easier to provide a better diagnostic for, compared to SR-12908.

@typesanitizer
Copy link
Author

@typesanitizer typesanitizer commented Mar 31, 2021

In the linked SR-14428, the issue is even worse since the compiler gives an actively misleading diagnostic.

@LucianoPAlmeida
Copy link
Collaborator

@LucianoPAlmeida LucianoPAlmeida commented Aug 26, 2021

Fixed by #39039

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants