Closed WojciechMazur closed 8 months ago
I don't think the bisect is correct. Both of those nightly versions crash with the -from-tasty
option for me
also pretty much any commit is failing to compile this code with testCompilation tests/pos/i19629.scala
even from way back to https://github.com/lampepfl/dotty/commit/44a537b340695dfa847fbda1ed12c60053c80deb and even https://github.com/lampepfl/dotty/commit/a4e669aeb5bad74ac6e46642875a5f296b2acbdb which are before any of the progress tracking stuff - i.e. im getting the same crash
@WojciechMazur this even crashes in the exact same way since 3.0.0, maybe you have some different steps to reproduce the "ok" version?
I assume that if it compiles fine with standard compilation, and fails only if --from-tasty
option is present then there must be something wrong in this compilation mode. There's more issues related to compilation --from-tasty
and I expected that everything that compiles from sources should also compile from tasty.
I'm fine to treat it as just a standard tasty error, but I'm wondering how you got it to not crash and instead make a normal error
with some improved debugging output, we get this error:
assertion failed: owner discrepancy for local type x @ 237, expected: local parameter ev @ 276, found: local method apply @ 153
this becomes clear why with the TASTy generated:
129: DEFDEF(161) 19 [visit]
133: TYPEPARAM(7) 20 [R]
136: TYPEBOUNDStpt(4)
138: SHAREDtype 17
140: SHAREDtype 23
142: PARAM(143) 21 [caseInFst]
146: REFINEDtpt(139)
149: TYPEREF 22 [PolyFunction]
151: SHAREDtype 19
153: DEFDEF(132) 23 [apply]
157: TYPEPARAM(18) 24 [F1]
160: LAMBDAtpt(15)
162: TYPEPARAM(7) 25 [[Unique _$ 6]]
165: TYPEBOUNDStpt(4)
167: SHAREDtype 17
169: SHAREDtype 23
171: TYPEBOUNDStpt(4)
173: SHAREDtype 17
175: SHAREDtype 23
177: TYPEPARAM(7) 26 [Y]
180: TYPEBOUNDStpt(4)
182: SHAREDtype 17
184: SHAREDtype 23
186: PARAM(23) 27 [k]
189: APPLIEDtpt(20)
191: IDENTtpt 2 [Knit]
193: TYPEREFsymbol 5
195: THIS
196: TYPEREFpkg 1 [<empty>]
198: IDENTtpt 3 [CP]
200: TYPEREFsymbol 12
202: THIS
203: SHAREDtype 193
206: IDENTtpt 24 [F1]
208: TYPEREFdirect 157
211: REFINEDtpt(74)
213: APPLIEDtpt(58)
215: TYPEREF 28 [Function1]
217: SHAREDtype 19
219: APPLIEDtpt(49)
221: IDENTtpt 29 [TypeEqK]
223: TYPEREF 29 [TypeEqK]
225: SHAREDtype 195
228: IDENTtpt 10 [F]
230: TYPEREFsymbol 41
232: SHAREDtype 202
235: LAMBDAtpt(33)
237: TYPEPARAM(7) 30 [x]
240: TYPEBOUNDStpt(4)
242: SHAREDtype 17
244: SHAREDtype 23
246: APPLIEDtpt(22)
248: IDENTtpt 3 [CP]
250: SHAREDtype 200
253: APPLIEDtpt(10)
255: IDENTtpt 24 [F1]
257: SHAREDtype 208
260: IDENTtpt 30 [x]
262: TYPEREFdirect 237
265: IDENTtpt 26 [Y]
267: TYPEREFdirect 177
270: TYPEREFdirect 133
273: DEFDEF(12) 23 [apply]
276: PARAM(4) 31 [ev]
279: SHAREDterm 219
282: IDENTtpt 20 [R]
284: SHAREDtype 270
287: SYNTHETIC
288: IDENTtpt 20 [R]
290: SHAREDtype 270
because the final result type (ev: TypeEqK[F, [x] =>> CP[F1[x], Y]]) => R
is a dependent function type, we end up duplicating the type arguments to Function1
in a refinement F1[G[[x] => x], R] { def apply(ev: G[[x] => x]): R }
. This is optimised in TASTy as a SHAREDterm
. Normally this is ok, but in this example, we cause a crash because we need to create two symbols that share the same address, and the TreeUnpickler isn't equipped for this.
Here is the trace:
at address 276
we re-index the parameters of apply
, starting with ev
, then we read the SHAREDterm 219
, which causes us to re-index the type lambda [x] =>> CP[F1[x], Y]
, starting with type parameter x @ 237
. The problem is that we already created a symbol at that address when we were indexing the result type of apply @ 153
, so currentSymbol
complains.
According to @sjrd this has to be fixed before it reaches TASTy, e.g. by having a type derived from the tree, rather than duplicating the tree - otherwise there's a whole mess in trying to keep track of which symbols have duplicates
Compilation from tasty of this code has always failed, however, recently it stated to crash compiler instead of returning error. This issue points to 2 bugs:
Compiler version
Last good release: 3.4.0-RC1-bin-20231030-e2c9dc0-NIGHTLY First bad release: 3.4.0-RC1-bin-20231031-58810fd-NIGHTLY Bisect points to 7fc4341dffdb32fb573b13c53c2611789a1ba640
Minimized code
Output (click arrow to expand)