Assertion failure in TypeErasure#sigName: "no sig for MethodType" #15649
Comments
griggt
added
itype:bug
itype:crash
regression
|
It seems as though there may be some non-determinism involved in this failure. While attempting to bisect it, it intermittently stopped reproducing (I've seen this behavior on Scastie as well, here's a run where it failed: https://scastie.scala-lang.org/OvLSO3O5SHCnicilO8PHrg). |
|
I compiled this on main once, compiled OK. I then cleaned the output directory (which is on my classpath) and compiled another 10 times. Everything compiled OK. Which makes me think that this is somehow sensitive to some unrelated class file on the class path. It would be good to find the commit that caused this, even though with the flakey behavior it will be diffcult. |
|
Yes, it looks highly non-deterministic. I could find out that it sees a MethodType that has another MethodType as parameter type, which makes no sense at all. But when I try to add an assertion to find out where it happens I can't make it crash again... |
If a getter TermRef has a MethodType, erase it to the erasure of the method result type. Fixes scala#15649 Since the fault in scala#15649 is highly non-deterministic, I can only guess what the reason was. I think what happened was that the TermRef was created very late, when the TermRef was already a getter. I.e. after phase `Getters`, which is itself after `Erasure`. The whole thing was launched from the code that generates static forwarders in the backend. Type erasure is run at erasure phase, but if there is no previous denotation of the `TermRef`, it will keep the first one it read, which would have the `MethodType` as underlying type. The end result was that the `TermRef` was erased to a method type, where it should have been erased to the result type. Consequently, we ended up with a MethodType as the parameter type of another method, which is unexpected. But all that is just a guess. I am not even sure this PR will fix the problem since it comes up so rarely.
mbovel
added
area:erasure
and removed
stat:needs triage
|
I spent some more time attempting to track this down. Today I used a significantly faster machine (i5-12400 vs. i5-4590s) and older JDK (8 vs. 17). For whatever reason, the behavior seemed more stable and the effort was more productive. I was able to replicate the crash as early as ae5f986 (the merge commit for #15129), but despite repeated efforts could not get it to crash on the parent merge commit a293d7d. Diving into the individual commits of that PR, it crashed on e609851 but not a690de2. So my best guess is the first bad commit is e609851 from #15129. |
I did worry about this sort of things at the time: #15129 (comment) :) |
If a getter TermRef has a MethodType, erase it to the erasure of the method result type. Fixes scala#15649 Since the fault in scala#15649 is highly non-deterministic, I can only guess what the reason was. I think what happened was that the TermRef was created very late, when the TermRef was already a getter. I.e. after phase `Getters`, which is itself after `Erasure`. The whole thing was launched from the code that generates static forwarders in the backend. Type erasure is run at erasure phase, but if there is no previous denotation of the `TermRef`, it will keep the first one it read, which would have the `MethodType` as underlying type. The end result was that the `TermRef` was erased to a method type, where it should have been erased to the result type. Consequently, we ended up with a MethodType as the parameter type of another method, which is unexpected. But all that is just a guess. I am not even sure this PR will fix the problem since it comes up so rarely.
If a getter TermRef has a MethodType, erase it to the erasure of the method result type. Fixes scala#15649 Since the fault in scala#15649 is highly non-deterministic, I can only guess what the reason was. I think what happened was that the TermRef was created very late, when the TermRef was already a getter. I.e. after phase `Getters`, which is itself after `Erasure`. The whole thing was launched from the code that generates static forwarders in the backend. Type erasure is run at erasure phase, but if there is no previous denotation of the `TermRef`, it will keep the first one it read, which would have the `MethodType` as underlying type. The end result was that the `TermRef` was erased to a method type, where it should have been erased to the result type. Consequently, we ended up with a MethodType as the parameter type of another method, which is unexpected. But all that is just a guess. I am not even sure this PR will fix the problem since it comes up so rarely.
If a getter TermRef has a MethodType, erase it to the erasure of the method result type. Fixes scala#15649 Since the fault in scala#15649 is highly non-deterministic, I can only guess what the reason was. I think what happened was that the TermRef was created very late, when the TermRef was already a getter. I.e. after phase `Getters`, which is itself after `Erasure`. The whole thing was launched from the code that generates static forwarders in the backend. Type erasure is run at erasure phase, but if there is no previous denotation of the `TermRef`, it will keep the first one it read, which would have the `MethodType` as underlying type. The end result was that the `TermRef` was erased to a method type, where it should have been erased to the result type. Consequently, we ended up with a MethodType as the parameter type of another method, which is unexpected. But all that is just a guess. I am not even sure this PR will fix the problem since it comes up so rarely.
Minimized from the community-build failure of zio/zio-config reported in #15647
Compiler version
3.2.0-RC2
Works on 3.1.3
Fails on 3.2.0-RC1
Fails on 3.2.1-RC1-bin-20220710-794e7c9-NIGHTLY
Minimized code
Output (click arrow to expand)
The text was updated successfully, but these errors were encountered: