-
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
@@ -1589,8 +1589,7 @@ class Typer extends Namer | |||
def isTreeType(t: untpd.Tree): Boolean = t match { | |||
case _: untpd.Apply => false | |||
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
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
someTree
should be typechecked as a term or atype.
If
someTree
isInt => 1
, dotty crashes becausetypedFunction
sees thatTree.isTerm
onInt => this
(or,untpd.Function(List('Int), 'this)
) givestrue
and callstypedFunctionValue
to typecheck this as a term.typedFunctionValue
then crashes on an unchecked pattern match, because'Int
becomes anIdent
and not aValDef
as it expects.Instead, I think
Int => 1
should be typechecked as a type, though I'm open to feedback.Really, we shouldn't call
isType
at 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