Skip to content
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

Package objects extending traits can crash multi-stage compilation #15980

Closed
WojciechMazur opened this issue Sep 6, 2022 · 5 comments · Fixed by #16097
Closed

Package objects extending traits can crash multi-stage compilation #15980

WojciechMazur opened this issue Sep 6, 2022 · 5 comments · Fixed by #16097
Labels
itype:bug regression This worked in a previous version but doesn't anymore stat:needs bisection Need to use nightly builds and git bisect to find out the commit where this issue was introduced
Milestone

Comments

@WojciechMazur
Copy link
Contributor

WojciechMazur commented Sep 6, 2022

Regression reproduced based on Open CB #4757 found in vitaliihonta/scala-ql (maintainer @vitaliihonta )
In the original build all files defined in submodules or tests placed in the same package (scalaql) were failing with large amount of errors related to cyclic references.

Part of the #15949 regression tracker

Compiler version

Fails in 3.2.1-RC1
Works in 3.2.0

Minimized code

The order of files within the compilation unit is important to reproduce:
Prefix ids combined with suffix unit id should allow to reproduce it in Vulpix
1st compilation unit:

// 1_syntax_1.scala
package scalaql.syntax

import scalaql.*

@forbiddenInheritance
trait ScalaqlSyntax
// 2_annotations_1.scala
package scalaql

import scala.annotation.StaticAnnotation

class forbiddenInheritance extends StaticAnnotation
// 3_package_1.scala
import scalaql.syntax.ScalaqlSyntax

package object scalaql extends ScalaqlSyntax

2nd compilation unit

// usage_2.scala
package scalaql

sealed trait Foo extends Product

Invocation:

scalac 1_syntax_1.scala 2_annotations_1.scala 3_package_1.scala 
scalac usage_2.scala 

Output

-- Error: usage_2.scala:3:25 -------------------------------------------------------------------------------------------------------------------
3 |sealed trait Foo extends Product
  |                         ^
  |                         Could not read definition of trait ScalaqlSyntax in ./scalaql/syntax/ScalaqlSyntax.class
  |                         An exception was encountered:
  |                           dotty.tools.dotc.core.CyclicReference: 
  |                         Run with -Ydebug-unpickling to see full stack trace.

Expectation

Should compile

@WojciechMazur WojciechMazur added itype:bug regression This worked in a previous version but doesn't anymore stat:needs triage Every issue needs to have an "area" and "itype" label labels Sep 6, 2022
@WojciechMazur
Copy link
Contributor Author

@KacperFKorban @nicolasstucki Do you think is a bisecting tool able to work with multi-stage compilation or can we adapt it. I'm worried mostly that checkouts between different commits would fail or overwrite local changes to bisect

@KacperFKorban
Copy link
Member

It can be reproduced without multi-stage, like so:

scalac -Ytest-pickler 1_syntax_1.scala 2_annotations_1.scala 3_package_1.scala 

So the only thing we would need is to handle scalac options in the bisect script, which should be doable. I'll try to do it this week.

@mbovel mbovel added stat:needs bisection Need to use nightly builds and git bisect to find out the commit where this issue was introduced and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Sep 12, 2022
@odersky
Copy link
Contributor

odersky commented Sep 25, 2022

@KacperFKorban Any news on the bisection side?

odersky added a commit to dotty-staging/dotty that referenced this issue Sep 25, 2022
@KacperFKorban
Copy link
Member

I tried bisecting it, but all I know at the moment it that:

Last good release: 3.2.1-RC1-bin-20220828-8a7c84c-NIGHTLY
First bad release: 3.2.1-RC1-bin-20220829-63344e7-NIGHTLY

So it was most likely introduced in #15877
But since some of the commits from that PR don't compile (most likely because of the large number of rebases) it's impossible to pinpoint the exact commit without manually fixing all of them and running the tests by hand.

@odersky
Copy link
Contributor

odersky commented Sep 25, 2022

@KacperFKorban Thanks for getting this far! That was actually enough to figure it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
itype:bug regression This worked in a previous version but doesn't anymore stat:needs bisection Need to use nightly builds and git bisect to find out the commit where this issue was introduced
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants