-
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.
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
equals
is overridden in the object, butequals
of object is also a bad practice