-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Literal null match error in ill-formed summon #16861
Comments
Minimizedgiven foo[T]: Any = summon[bar]
def bar: Nothing = ??? |
@WojciechMazur, this failure looks like one of the failures in the extended community build that you showed us. Is this the case, or am I misremembering? |
This does not crash in 3.2.2. It fails compilation with [error] Test.scala:1:28: Not found: type bar
[error] given foo[T]: Any = summon[bar]
[error] ^^^ |
Started in ebb616c |
@nicolasstucki yes, that seems to be exactly the same case as in these two projects:
|
Harden tpd.Apply/TypeApply in case of errors to accept non-sensical terms as functions. Fixes scala#16861
I have a fix in #16887 where the crashes are avoided and these examples are now rejected. in particular I get for the original code fragment: -- [E008] Not Found Error: i16861a.scala:4:46 ----------------------------------
4 | inline given foo[T <: Foo]: T = summon[Type.of[Foo]] // error
| ^^^^^^^
| type of is not a member of object quoted.Type
1 error found But that error looks strange to me as well. I would have expected it to compile or at least give another error since |
Harden tpd.Apply/TypeApply in case of errors to accept non-sensical terms as functions. Fixes #16861
The "hardening" added in the fix for this issue is blowing up for me:
I'm far from being able to minimize the issue. It occurred in an existing module with about 20 dependencies, and appeared after a refactor of some dependee modules. What I would ask for is more context to help me narrow down where this originates in my code. The assert fails because an error was expected, but there is none:
If the assert also reported something about what/where |
So as so often happens, the AssertionError mentioned above was associated with an underlying compile error, which unfortunately was then (from my POV at least) obscured by the assertion blowing up and preventing underlying errors from being reported. The only usable diagnostic I had to go on was this output:
By splitting the code in Can I plead for more informative/diagnostic info for all compiler crashes? In industrial usage in a big, multi-layered codebase using libraries, truth is minimization of a crash can be extremely difficult. So it may well go unreported to dotty team; the issue templates request a minimized example as mandatory for crash reports. As an early adopter of Scala 3, we users often will need to work-around, rather than fix, a compiler crash. Having context about what was going on at the crash point helps us to do this. |
it would have blown up before as well, with a |
These are valid prefixes for a TypeApply in the same way they are for an Apply. See scala#16861 (comment)
These are valid prefixes for a TypeApply in the same way they are for an Apply. See scala#16861 (comment)
I opened #18700 to address this new issue. |
<del> These are valid prefixes for a TypeApply in the same way they are for an Apply. See #16861 (comment) </del>
Compiler version
3.3.0-RC2
Minimized code
Output (click arrow to expand)
The text was updated successfully, but these errors were encountered: