-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix ClassCastException upon class Foo extends Int => <someTerm>
#4487
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
|
Assigned to Martin as decided in the meeting. |
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.
I agree with the reasoning, but think we can cut it even more clearly. If you look at what the parser does (in constrApp), it produces either a type or a New expression applied to arguments. So I believe we can just check whether the parent is an Apply node and type it as a term, or type it as a type otherwise.
Can you try this and see whether it works?
|
@Blaisorblade Inactive for 6 months. What will happen with this? |
aee57aa to
2361d2c
Compare
| case _: untpd.Select => | ||
| // Could be produced by parsing incomplete argument lists. | ||
| assert(false, "Raw Select node found in constructor position") | ||
| // Can be produced for absent argument lists. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
1b7f94f to
d21db0a
Compare
|
Last commit is from #5721 to allow tests to pass. |
To typecheck ```scala class Foo extends someTree ``` we need to detect correctly if `someTree` should be typechecked as a term or a type; `Int => 1` should be typechecked as a type, even though it looks like a term according to `isTerm`. Really, we shouldn't use isType at all, because the user might write a type in place of a term or viceversa. I think we only want to know this is a constructor call or a type; and maybe we should just let the parser tell us which, since it knows.
d21db0a to
2732c6b
Compare
biboudis
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.
I tested it with a partial functions and implicit function types and it works. They could be added as tests but this looks already good.
To successfully typecheck
we need to detect correctly if
someTreeshould be typechecked as a term or atype.
If
someTreeisInt => 1, dotty crashes becausetypedFunctionsees thatTree.isTermonInt => this(or,untpd.Function(List('Int), 'this)) givestrueand callstypedFunctionValueto typecheck this as a term.typedFunctionValuethen crashes on an unchecked pattern match, because'Intbecomes anIdentand not aValDefas it expects.Instead, I think
Int => 1should be typechecked as a type, though I'm open to feedback.Really, we shouldn't call
isTypeat all, because the user might write a type inplace of a term or viceversa. I think we only want to know this is a constructor
call or a type; and maybe we should just let the parser tell us which, since it
knows.
Minimized from a testcase in #4389, in particular:
which triggers