Open Zschimmer opened 6 months ago
SethTisue
commented
6 months ago Is the problem reproducible without involving sbt?
It can be helpful to run sbt -debug to get more logging about exactly what's going on. In particular, it will show you scalac and javac invocations that you can then separately attempt outside of the build tool, as a way of cutting sbt out of the picture. (Or, perhaps the invocations will make it plain that it's sbt going wrong here.)
Zschimmer
commented
6 months ago Below the scalac command with the same output: AssertionError: assertion failed: NoType. The error appears immediately. It's repeatable. The command compiles all .scala and .java files of the subproject, gathered with $(find ...).
Not sure if it helps. The subproject depends on other subprojects which I compiled with sbt. There are many third-party dependencies, too. A complete compilation without sbt would require the extraction of 48 scalac commands and several downloads of third party libraries (it's great to have sbt!).
Gedochao
commented
6 months ago @Zschimmer Any chance you'd be able to minimize this further in the near future?
Zschimmer
commented
6 months ago The following snippet shows the same exception, without the "cyclic reference involving class" error.
val KeyedEvent(NoKey, event) = ???
/// Event ///
trait Event:
type KeyBase <: Event
val keyCompanion: Event.KeyCompanion[KeyBase]
object Event:
trait KeyCompanion[E <: Event]:
type Key
/// KeyedEvent ///
final class KeyedEvent[+E <: Event](val event: E)(val key: event.keyCompanion.Key)
object KeyedEvent:
def unapply[E <: Event](ke: KeyedEvent[E]): (ke.event.keyCompanion.Key, E) =
ke.key -> ke.event
/// NoKey ///
case object NoKeyScastie shows this, too: https://scastie.scala-lang.org/5vDJcHrQTRysv9SRwIuA3g
It's not clear to me why this (radically reduced) snippet shows the behaviour whereas the same parts scattered in the code compiles as expected (as long as the Scala files are placed in the scala subdirectory!).
I have several groups of events, where each group is associated with a key (or the dummy NoKey). The type of the key is determined via the dependent type keyCompanion.Key. KeyedEvent contains both the Event and its key.
The snippet does not have a real event. In the real code, the type of keyCompanion.Key is defined and known.
Compiler version
Scala 3.3.3 sbt 1.9.9 Java 21.0.2
Minimized code
I am sorry, it’s not easy to minimize it. It happened after a merge commit. I reduced to a single code line which switches the crash on and off.
Also, due to a mistake, this Scala source file is placed in a java source directory. If I move the file to the corresponding scala source directory, the compiler succeeds.
How to reproduce
It's reproducible with
(the compilation takes two minutes)
The single line which switches the crash on and off is in the file
js7-tests/src/test/java/js7/tests/controller/proxy/ScalaCompilerKnockOut.scala, the wordcontrollerAdmission.When you prefix this line with a comment, and clean and compile again, the compilation succeed. Same result, if you move the file from the java to the scala source code directory.
It’s enough to clean and recompile the js7-tests subproject. Clean is required, otherwise the incremental compilation may succeed, while a clean compilation does not succeed.
Output (click arrow to expand)
The compilations errors occur only if this 'controllerAdmission' line is active.
There are some warnings about unused imports, which are required for compilation, nevertheless. This is something else.
(IntelliJ IDEA is not happy with the code, because build.sbt still contains crossproject subprojects.)