Closed pshirshov closed 6 months ago
@odersky , that's the issue I mentioned during our conversation.
In order to reproduce on izumi:
./sbtgen.sc --js
++ 3
in the sbt shell followed by ;clean;test:compile
Watch the build log. There will be stacktraces like:
The build will succeed regardless. It might be interesting that the "problematic" classes differ from run to run. That makes me think that it might be some kind of a race condition in the compiler.
I still can't isolate it but it is easily reproducible and, as you requested, the stacktraces are available.
I'm seeing what looks to be an identical crash in one of my own projects. Scala 3.2.2, SBT 1.8.2, Java 18.0.2 on Linux x86_64.
This is a project using ScalikeJDBC 4.0.0 and the assertion is thrown only when compiling tests (i.e. "sbt test"). I can compile the project successfully (i.e. "sbt clean compile") every time - the assertion has something to do with my test classes it seems. The referenced "AutoRollback" trait is from ScalikeJDBC, not from my code.
It's probably not a race condition but a an error that depends on the order of files to be compiled. And the problem seems to be (as almost always) that there is a cyclic reference that the compiler cannot resolve.
I think it would be important to minimize it but I don't have the time. Can someone help me here?
The problem of @pshirshov looks like it can easily be avoided since it happens during import suggestions and we can simply turn off the assert then.
The problem of @Nexus6 is more serious and harder to fix. Essentially we end up with an illegal state in a core operation -- computing the base types of a type. I could simply turn off the assert and return no base type, but I really would like to find out what goes wrong here because this could be a deeper problem. Turning off the assert would simply mask the underlying problem which will make it much less likely to be fixed.
A minimization should be a small number of self contained files that demonstrates the problem. Typically it goes like this:
Ok, I'll try.
@pshirshov Thanks! But I actually think it would be easier to start with the problem experienced by @Nexus6. The problem you are seeing is when the compiler tries to find suggestions for imports. That process depends not just on the files you compile and their dependencies but the whole classpath. That makes it hard to reproduce by definition. As far as I can see the problem experienced by @Nexus6 is a full compiler crash for normal compilation. As a first step it would be good to find out whether it is still present in 3.3.0.
@odersky To create a reproducible test case, I used vscode+metals to create a minimal sbt project from the Scala3 template. To this I added the ScalikeJDBC, specs2, and munit dependencies from the project where I originally observed the crash. In addition, I added a stripped-down version of one of the test classes that was originally generated for me, from an existing db schema, by ScalikeJDBC.
Github is not allowing me to attach the project archive (.tar.gz - 1.2K) here but you can download it here or let me know of some other way I can get it to you if you're interested.
Just download, unpack, switch to the new project directory, run "sbt test" and the crash should happen every time. I tested this on my x86_64 machine and on an ARM64 machine - same crash. Interestingly, the test class shouldn't compile at all as I left the source file for the "Header" model class out of the project. But the crash occurs before the compiler even gets to the point of complaining about the missing class.
We spotted another strange trace in come code using izumi-reflect. We'll try to isolate it but as with the previous trace it might be tricky.
java.lang.AssertionError: assertion failed: class Array
at scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:8)
at dotty.tools.backend.jvm.BCodeHelpers.primitiveOrClassToBType$1(BCodeHelpers.scala:713)
at dotty.tools.backend.jvm.BCodeHelpers.dotty$tools$backend$jvm$BCodeHelpers$$typeToTypeKind(BCodeHelpers.scala:733)
at dotty.tools.backend.jvm.BCodeHelpers$BCInnerClassGen.toTypeKind(BCodeHelpers.scala:201)
at dotty.tools.backend.jvm.BCodeHelpers$BCInnerClassGen.toTypeKind$(BCodeHelpers.scala:129)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.toTypeKind(BCodeSkelBuilder.scala:74)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genConstant(BCodeBodyBuilder.scala:578)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadTo(BCodeBodyBuilder.scala:447)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoad(BCodeBodyBuilder.scala:303)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.loop$1(BCodeBodyBuilder.scala:1202)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadArguments(BCodeBodyBuilder.scala:1209)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genApply(BCodeBodyBuilder.scala:832)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadTo(BCodeBodyBuilder.scala:382)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadTo(BCodeBodyBuilder.scala:462)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoad(BCodeBodyBuilder.scala:303)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.loop$1(BCodeBodyBuilder.scala:1202)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadArguments(BCodeBodyBuilder.scala:1209)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genApply(BCodeBodyBuilder.scala:832)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadTo(BCodeBodyBuilder.scala:382)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoad(BCodeBodyBuilder.scala:303)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genStat(BCodeBodyBuilder.scala:117)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genBlockTo$$anonfun$1(BCodeBodyBuilder.scala:1087)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10)
at scala.collection.immutable.List.foreach(List.scala:333)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genBlockTo(BCodeBodyBuilder.scala:1087)
at dotty.tools.backend.jvm.BCodeBodyBuilder$PlainBodyBuilder.genLoadTo(BCodeBodyBuilder.scala:454)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.emitNormalMethodBody$1(BCodeSkelBuilder.scala:827)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.genDefDef(BCodeSkelBuilder.scala:850)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.gen(BCodeSkelBuilder.scala:632)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.gen$$anonfun$1(BCodeSkelBuilder.scala:638)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10)
at scala.collection.immutable.List.foreach(List.scala:333)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.gen(BCodeSkelBuilder.scala:638)
at dotty.tools.backend.jvm.BCodeSkelBuilder$PlainSkelBuilder.genPlainClass(BCodeSkelBuilder.scala:233)
at dotty.tools.backend.jvm.CodeGen.genClass(CodeGen.scala:138)
at dotty.tools.backend.jvm.CodeGen.genClassDef$1(CodeGen.scala:55)
at dotty.tools.backend.jvm.CodeGen.genClassDefs$1(CodeGen.scala:101)
at dotty.tools.backend.jvm.CodeGen.genClassDefs$1$$anonfun$1(CodeGen.scala:99)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10)
at scala.collection.immutable.List.foreach(List.scala:333)
at dotty.tools.backend.jvm.CodeGen.genClassDefs$1(CodeGen.scala:99)
at dotty.tools.backend.jvm.CodeGen.genUnit(CodeGen.scala:104)
at dotty.tools.backend.jvm.GenBCode.run(GenBCode.scala:76)
at dotty.tools.dotc.core.Phases$Phase.runOn$$anonfun$1(Phases.scala:327)
at scala.collection.immutable.List.map(List.scala:250)
at dotty.tools.dotc.core.Phases$Phase.runOn(Phases.scala:331)
at dotty.tools.backend.jvm.GenBCode.runOn(GenBCode.scala:87)
at dotty.tools.dotc.Run.runPhases$1$$anonfun$1(Run.scala:246)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10)
at scala.collection.ArrayOps$.foreach$extension(ArrayOps.scala:1321)
at dotty.tools.dotc.Run.runPhases$1(Run.scala:262)
at dotty.tools.dotc.Run.compileUnits$$anonfun$1(Run.scala:270)
at dotty.tools.dotc.Run.compileUnits$$anonfun$adapted$1(Run.scala:279)
at dotty.tools.dotc.util.Stats$.maybeMonitored(Stats.scala:67)
at dotty.tools.dotc.Run.compileUnits(Run.scala:279)
at dotty.tools.dotc.Run.compileSources(Run.scala:194)
at dotty.tools.dotc.Run.compile(Run.scala:179)
at dotty.tools.dotc.Driver.doCompile(Driver.scala:37)
at dotty.tools.xsbt.CompilerBridgeDriver.run(CompilerBridgeDriver.java:88)
at dotty.tools.xsbt.CompilerBridge.run(CompilerBridge.java:22)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:91)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$7(MixedAnalyzingCompiler.scala:193)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:248)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$4(MixedAnalyzingCompiler.scala:183)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$4$adapted(MixedAnalyzingCompiler.scala:163)
at sbt.internal.inc.JarUtils$.withPreviousJar(JarUtils.scala:239)
at sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:163)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:211)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:534)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:534)
at sbt.internal.inc.Incremental$.$anonfun$apply$5(Incremental.scala:180)
at sbt.internal.inc.Incremental$.$anonfun$apply$5$adapted(Incremental.scala:178)
at sbt.internal.inc.Incremental$$anon$2.run(Incremental.scala:464)
at sbt.internal.inc.IncrementalCommon$CycleState.next(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon$$anon$1.next(IncrementalCommon.scala:56)
at sbt.internal.inc.IncrementalCommon$$anon$1.next(IncrementalCommon.scala:52)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:263)
at sbt.internal.inc.Incremental$.$anonfun$incrementalCompile$8(Incremental.scala:419)
at sbt.internal.inc.Incremental$.withClassfileManager(Incremental.scala:506)
at sbt.internal.inc.Incremental$.incrementalCompile(Incremental.scala:406)
at sbt.internal.inc.Incremental$.apply(Incremental.scala:172)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:534)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:488)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:332)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:425)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:137)
at sbt.Defaults$.compileIncrementalTaskImpl(Defaults.scala:2369)
at sbt.Defaults$.$anonfun$compileIncrementalTask$2(Defaults.scala:2319)
at sbt.internal.server.BspCompileTask$.$anonfun$compute$1(BspCompileTask.scala:31)
at sbt.internal.io.Retry$.apply(Retry.scala:47)
at sbt.internal.io.Retry$.apply(Retry.scala:29)
at sbt.internal.io.Retry$.apply(Retry.scala:24)
at sbt.internal.server.BspCompileTask$.compute(BspCompileTask.scala:31)
at sbt.Defaults$.$anonfun$compileIncrementalTask$1(Defaults.scala:2317)
at scala.Function1.$anonfun$compose$1(Function1.scala:49)
at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:63)
at sbt.std.Transform$$anon$4.work(Transform.scala:69)
at sbt.Execute.$anonfun$submit$2(Execute.scala:283)
at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:24)
at sbt.Execute.work(Execute.scala:292)
at sbt.Execute.$anonfun$submit$1(Execute.scala:283)
at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:265)
at sbt.CompletionService$$anon$2.call(CompletionService.scala:65)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Actually, this time the repro is stable and laughably simple: https://scastie.scala-lang.org/lUnGyx2XSXu81ZLWKCvw8A
@odersky
I've been getting errors like cannot be unpickled because no class file was found for denot: val <none>
, but at the scaladoc
stage of my build rather than compile
. I hit this in mill
, but it's easy to reproduce in scala-cli
.
Start with a file hello.txt.scala
:
def hello(name : String) : String = s"Hi $name"
Place it alone in a directory and cd
in. Then
% scala-cli doc .
Compiling project (Scala 3.3.0, JVM)
Compiled project (Scala 3.3.0, JVM)
class hello.txt$package cannot be unpickled because no class file was found for denot: val <none>
1 error found
[error] Scaladoc generation failed (exit code: 1)
If you build the jar file and use the scaladoc
shell command on that, it will seem to work, but nothing will have been documented, there will be no index.html
in the output dir.
That's probably just a default package thing! If you put a package declaration in hello.txt.scala
, build a jar file and run scaladoc
, you'll see the sole function documented in <pacakge-name>.html
.
So, from a jar file it works. But if you compile, search .scala-build
to find the tasty .tasty
file, and try to scaladoc
from that, you get...
% find .scala-build -name '*.tasty' -print
.scala-build/unpickle-bug_103be31561/classes/main/hello$u002Etxt$package.tasty
.scala-build/.bloop/unpickle-bug_103be31561/bloop-internal-classes/main-Q--LQ5riT_266sHJJdSS2w==/hello$u002Etxt$package.tasty
% cd .scala-build/unpickle-bug_103be31561/classes/main/
% mkdir scala-doc
% scaladoc -d scala-doc 'hello$u002Etxt$package.tasty'
class hello.txt$package cannot be unpickled because no class file was found for denot: val <none>
1 error found
Ah ha!
Everything works (including scaladoc from the tasty file) if you just rename the file hello.scala
and build from that.
TL; DR: Avoid source file names with .
characters before the .scala
The error message could be a bit clearer, though.
@pshirshov Thanks! But I actually think it would be easier to start with the problem experienced by @Nexus6. The problem you are seeing is when the compiler tries to find suggestions for imports. That process depends not just on the files you compile and their dependencies but the whole classpath. That makes it hard to reproduce by definition. As far as I can see the problem experienced by @Nexus6 is a full compiler crash for normal compilation. As a first step it would be good to find out whether it is still present in 3.3.0.
@odersky I'm still seeing this crash on 3.3.1 (Linux, x86_64 and ARM64, openjdk 19.0.2 & 21-ea) with sbt 1.9.5.
[info] tree: EmptyTree
[info] tree position: :
Actually, this time the repro is stable and laughably simple: https://scastie.scala-lang.org/lUnGyx2XSXu81ZLWKCvw8A
@pshirshov's minimization is still valid:
//> using dep dev.zio::izumi-reflect:2.3.8
import izumi.reflect.Tag
@main def main = println(Tag[Array[Byte]])
We still need a minimization without the izumi-reflect
dependency, however.
Well, as @odersky said once, our macros are one of the toughest compiler stresstests. These things are prohibitively hard to untangle.
The Tag[Array[Byte]]
is a totally different issue. That one is most likely the macro's fault: it generates a classOf[Array]
instead of classOf[Array[Byte]]
. classOf[Array]
makes no sense since it is ill-kinded.
@Nexus6 Your link is not active anymore. Is there any chance you could repost your reproduction to somewhere more stable?
I could reliably reproduce https://github.com/scala/scala3/issues/16036#issuecomment-1426022497 on 3.2.2. On the latest main
of scala3, however, several runs have not reported any AssertionError
in the logs. It seems to me that this was fixed at some point.
Note that to be able to compile all the tests on the nightly, I had to apply the following change to the test sources. The previous code was rule out as unsound.
diff --git a/distage/distage-testkit-scalatest/src/main/scala-3/izumi/distage/testkit/scalatest/SpecWiring.scala b/distage/distage-testkit-scalatest/src/main/scala-3/izumi/distage/testkit/scalatest/SpecWiring.scala
index 620e618d4..4aebd4d30 100644
--- a/distage/distage-testkit-scalatest/src/main/scala-3/izumi/distage/testkit/scalatest/SpecWiring.scala
+++ b/distage/distage-testkit-scalatest/src/main/scala-3/izumi/distage/testkit/scalatest/SpecWiring.scala
@@ -3,14 +3,14 @@ package izumi.distage.testkit.scalatest
import izumi.distage.framework.{CheckableApp, PlanCheckConfig, PlanCheckMaterializer}
import izumi.distage.modules.DefaultModule
-abstract class SpecWiring[AppMain <: CheckableApp, Cfg <: PlanCheckConfig.Any](
+abstract class SpecWiring[F[_], AppMain <: CheckableApp { type AppEffectType[X] = F[X] }, Cfg <: PlanCheckConfig.Any](
val app: AppMain,
val cfg: Cfg = PlanCheckConfig.empty,
val checkAgainAtRuntime: Boolean = true,
)(implicit
val planCheck: PlanCheckMaterializer[AppMain, Cfg],
- defaultModule: DefaultModule[app.AppEffectType],
-) extends Spec1[app.AppEffectType]()(app.tagK, defaultModule)
+ defaultModule: DefaultModule[F],
+) extends Spec1[F]()(app.tagK, defaultModule)
with WiringAssertions {
s"Wiring check for `${planCheck.app.getClass.getCanonicalName}`" should {
However, that is not related to the previous crash. Even with that fix, 3.2.2 still reliably logged AssertionError
s.
@Nexus6 Your link is not active anymore. Is there any chance you could repost your reproduction to somewhere more stable?
Sorry about that. I pushed to a new repo, you can grab the code here: https://github.com/Nexus6/dotty16036.git . Just run "sbt test" on it.
The crash is still happening on 3.4.1, when compiling the HeaderSpec.scala class. I'm seeing
[error] java.lang.AssertionError: assertion failed: trait AutoRollback has non-class parent: TypeRef(TermRef(ThisType(TypeRef(NoPrefix,moduleclass specs2)),object mutable),After) [error] at scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:8) [error] at dotty.tools.dotc.core.SymDenotations$ClassDenotation.traverse$1(SymDenotations.scala:1999) [error] at dotty.tools.dotc.core.SymDenotations$ClassDenotation.computeBaseData(SymDenotations.scala:2004) [error] at dotty.tools.dotc.core.SymDenotations$BaseDataImpl.apply(SymDenotations.scala:2996) [error] at dotty.tools.dotc.core.SymDenotations$ClassDenotation.baseData(SymDenotations.scala:1970) [error] at dotty.tools.dotc.core.SymDenotations$ClassDenotation.baseClassSet(SymDenotations.scala:1986) [error] at dotty.tools.dotc.core.SymDenotations$ClassDenotation.derivesFrom(SymDenotations.scala:2012) [error] at dotty.tools.dotc.core.Types$Type.loop$1(Types.scala:279) [error] at dotty.tools.dotc.core.Types$Type.derivesFrom(Types.scala:303) [error] at dotty.tools.dotc.typer.Namer$ClassCompleter.checkedParentType$1(Namer.scala:1556) [error] at dotty.tools.dotc.typer.Namer$ClassCompleter.$anonfun$29(Namer.scala:1624) [error] at scala.collection.immutable.List.map(List.scala:246)
Thanks.
I minimized down to using only the following dependency:
"org.scalikejdbc" %% "scalikejdbc-test" % "4.0.0"
with the following Scala code:
import scalikejdbc.specs2.mutable.AutoRollback
class Foo extends AutoRollback
It still crashes on the main
branch, with the same error message.
OK looks to me like it makes sense, actually. There is no org.specs2.mutable.After
type at all in version 5.2.0, which is referenced from the build.
The scalikejdbc-test
dependency does not seem to declare an actual dependency to specs2
, but contains references to its org.specs2.mutable.After
. I guess it was compiled a previous version of Specs2 that did define that class. Usually this would result in a resolution warning/error in sbt, saying that 2 incompatible versions of a library are requested. But here, since there is no explicit dependency, sbt cannot possibly tell.
So it doesn't seem like a bug in the compiler to me. It seems like a corrupted/mis-published library.
Using the following dependencies fixes the issue:
libraryDependencies ++= Seq(
"org.scalikejdbc" %% "scalikejdbc-test" % "4.0.0",
"org.specs2" %% "specs2-core" % "4.20.5",
)
So yes, I don't think this is a compiler issue.
Nice sleuthing. Can confirm that your test-case tweak of using specs2-core 4.20.5 makes the assertion error go away - no more compiler crash.
My question is then: is a fatal AssertionError with a cryptic error message the best way to handle this condition in the released builds of the compiler? Could it, and should it, be handled in a more user-friendly way? From your description of the problem it sounds like this might be a fairly common occurrence, so maybe 1) issue an informative error message, then 2) perform an orderly compiler exit?
The
scalikejdbc-test
dependency does not seem to declare an actual dependency tospecs2
, but contains references to itsorg.specs2.mutable.After
.
This is the core issue. That library must have actively configured something to go against the current. In doing so, they are bypassing the user-friendly checks that are normally in place. There's not much we can do about that, I'm afraid.
I'm going to optimistically close this issue, since I believe I have exhausted all the reproductions that have been mentioned in this thread. Feel free to reopen if it still happens on nightly, or on the soon-to-be-released 3.5.0-RC1.
3.1.3
This looks some kind of a race condition in the compiler because it's not always happening on my machine.
From time to time I'm getting output like this while compiling classes which use
BIOCatsMonad
In my case this does not prevent the compiler from going further though other users report compiler crashes with messages like
At this moment I cannot produce minimal repro and even reliable repro, I wasn't able to reproduce the crashes too.