Nondeterministic compiler crash on clean compile (ClassCastException: PolyType, CachedTermRef) #16884
Comments
hnaderi
added
itype:bug
itype:crash
stat:needs triage
|
"ClassCastException: dotty.tools.dotc.core.Types$CachedTermRef cannot be cast to dotty.tools.dotc.core.Types$PolyType" isn't one I've seen before. at minimum, perhaps others who see the same error will search and land here and perhaps have some insight you seem to have double-pasted the stack trace; mind cleaning that up? |
SethTisue
changed the title
|
perhaps once #16593 lands you'll be able to include more useful diagnostic information in the report (and that might help with minimizing, too... minimizing it is the usual path towards an actual fix) |
Oops! thanks for pointing out that, just cleaned it up. |
|
Is the crash happening on a public codebase you could link us to? That could help us investigate the issue without a minimization. |
|
Yes, it's an opensource project. How to reproduce:
It might take a few retries to see the error happening. |
|
Thanks, it seems that the issue is easier to reproduce if I reduce the size of the heap by setting The crash happens on https://github.com/hnaderi/lepus/blob/fecc7c7e793b98b9f9a85eac89856ee51baf2b6a/modules/client/src/test/scala/internal/ChannelOutputSuite.scala#L97 when PostTyper sees This appears to be due to cache pollution: Sometimes, the IMO, |
smarter
added
area:typer
and removed
stat:needs triage
That must have been hard to spot! But I am not sure it's the mutation itself which is to blame. If |
|
One idea could be to copy the EDIT: In fact, that happens already. But the opposite does not: If the previous designatore is a symbol and the denotation is overloaded, we keep the symbol. 16324c1 tries to use the name instead. |
When creating a NamedType with a given overloaded denotation, make sure that the type has a Name as designator. This prevents accidentally overwriting a more precise symbolic TermRef that refers to one specific alternative of the denotation. This might be enough to fix scala#16884. It would be great if we could maintain the general invariant that NamedTypes with overloaded denotations always have names as designators. But that looks very hard when we take into account that we need to update named types to new runs. A type might have a single denotation in one round and an overloaded one in the next.
When creating a NamedType with a given overloaded denotation, make sure that the type has a Name as designator. This prevents accidentally overwriting a more precise symbolic TermRef that refers to one specific alternative of the denotation. This might be enough to fix scala#16884. It would be great if we could maintain the general invariant that NamedTypes with overloaded denotations always have names as designators. But that looks very hard when we take into account that we need to update named types to new runs. A type might have a single denotation in one round and an overloaded one in the next.
When creating a NamedType with a given overloaded denotation, make sure that the type has a Name as designator. This prevents accidentally overwriting a more precise symbolic TermRef that refers to one specific alternative of the denotation. This might be enough to fix #16884. EDIT: It wasn't enough but the second commit [46e82dd](46e82dd) should fix it. The second commit never overwrites in `withDenot`. It can do that because we fix `infoDependsOnPrefix` to work correctly for abstract types that are refined in a self type. It turned out that previously we needed some TypeRefs to keep their Name designators because that way we would recompute their info with a `member` operation. If these TypeRefs had a symbol designator they would be recomputed wrongly by `symd.current` in `fromDesignator` because the preceding `infoDependsOnPrefix` test was faulty. It would be great if we could maintain the general invariant that NamedTypes with overloaded denotations always have names as designators. But that looks very hard when we take into account that we need to update named types to new runs. A type might have a single denotation in one round and an overloaded one in the next.
Compiler version
I tried with these versions
3.2.2 ,3.2.1, 3.2.0
Minimized code
I couldn't reproduce an independent minimized code yet, as it is hard to check whether the issue is gone or is not appearing due to some other change.
Output (click arrow to expand)
The text was updated successfully, but these errors were encountered: