-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix #9740: harden type checking for pattern match on objects #11327
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
Conversation
2c72a6c to
ea11087
Compare
|
test performance please |
|
performance test scheduled: 13 job(s) in queue, 1 running. |
|
|
||
| // Case 3: Same as above; should match the second case and print the length of the string | ||
| any match { | ||
| case C(IsInt, i) if i < 10 => println(s"An Int less than 10") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no checkfile for neg tests?? Sounds very unstable to not verify the failure reasons...
I wanted to see on what grounds this now fails to compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We tend to avoid check files as they incur maintenance overhead. In contrast, we check the line numbers of reported errors agree with the comments // error in the source code.
dwijnand
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, with 1 jaw-dropping realisation...
We enforce that when pattern match on an object, the object should be a subtype of the scrutinee type. Reasons for doing so: - such code patterns usually implies hidden errors in the code - it's always safe/sound to reject the code We could check whether `equals` is overridden in the object, but - it complicates the protocol - overriding `equals` of object is also a bad practice - there is no sign that the slightly improved completeness is useful
ea11087 to
b04150c
Compare
| mapOver(tp) | ||
| } | ||
|
|
||
| if tree.symbol.is(Module) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to check this also for other values that are not modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot check non-module values due to aliasing.
This is a follow-up of scala#11327.
This is a follow-up of scala#11327. We cannot generalize further without complications: ``` val b = 'b' 56 match case 'a' => case `b` => ```
This is a follow-up of scala#11327. We cannot generalize further without complications: ``` val b = 'b' 56 match case 'a' => case `b` => ```
Fix #9740: harden type checking for pattern match on objects
We enforce that when pattern match on an object, the object should be
a subtype of the scrutinee type. It aligns with Scala 2 behavior.
Reasons for doing so:
We could check whether
equalsis overridden in the object, butequalsof object is also a bad practice