knownDirectSubclasses of <class> observed before subclass <class> registered

[joan38]

In:
https://github.com/joan38/orchestra/tree/6d2c170f37040f2179479c6126292e030808ed08

Just rename:
orchestra/src/main/scala/com/goyeau/orchestra/ARunStatus.scala
to:
orchestra/src/main/scala/com/goyeau/orchestra/RunStatus.scala

And enjoy:

[error] knownDirectSubclasses of RunStatus observed before subclass Running registered
[error] knownDirectSubclasses of RunStatus observed before subclass Success registered
[error] two errors found
[error] (orchestraJVM/compile:compileIncremental) Compilation failed

Related:
lloydmeta/enumeratum#90
https://issues.scala-lang.org/browse/SI-7046
scala/scala#5284

Using:
Scala 2.12.2
Circe 0.8.0

[lloydmeta]

I've been wondering about this one for a while as well and finally got around to successfully reproducing it. I had a bit of trouble reproducing it because it is highly dependent on the order in which things get compiled.

Here's my attempt at a minimal repro: https://github.com/lloydmeta/circe-auto-derive-repro

[ngbinh]

@lloydmeta @joan38 putting the extending classes and objects inside the companion object of the sealed trait will cause knownDirectSubclasses (sometimes can be intermittently due to incremental compiling).

[lloydmeta]

@ngbinh from what I can see, it definitely depends on whether or not that trait/object get compiled before import io.circe.generic.auto._ gets hit.

I mentioned this in the readme of my repo, but I'll paste it here as well

There are 2 ways to make compilation pass:

1. Rename Role to ARole.
2. Add import Role._ at the top of Main, before import io.circe.generic.auto._

[ngbinh]

@lloydmeta yeah, you need to at least try to derive Encoder/Decoder for a sealed trait to get knowDirectSubclass. I believe knownDirectSubclass is used by shapeless to compute all the subclasses of a sealed trait. This https://github.com/circe/circe-derivation may help once it is released.

I also think this problem only exists in scala 2.12 as we were fine in 2.11.

[lloydmeta]

BTW, this Scastie snippet is decidedly oddly written, but shows that you can reproduce the same error without putting the ADT members inside the companion object.

[travisbrown]

For what it's worth this is probably the same root issue as #434. I don't think there's a lot we can do here, but fortunately things on the knownDirectSubclasses front are gradually improving on the compiler side (I'm not sure what's up with @ngbinh's regression, though).

What I'd personally like to see is a detailed section in the docs about the places this will come up, and potential workarounds. I'm not sure when I'll get around to writing it myself, though. ☹️

[lloydmeta]

@travisbrown yea, it definitely seems to be related. As @witi83 noted in the lloydmeta/enumeratum#90, this seems to have started after 2.11.8 (EDIT for poor wording: as in, it works with 2.11.8, breaks in 2.11.x releases after that). I've verified this to be the case and added a note to my repro repo as well..

I'll be glad to help add something to the docs about this, just as soon as I actually understand what is going on. I think a lot of ppl thought this problem was already fixed.

EDIT: filed a bug report (scala/bug#10330) to find out more about the regression-looking side of things.

[ngbinh]

right after upgrading to 2.12.0 (which contains this scala/scala#5284 ), we've seen a lot more cases of knownDirectSubclasses in incremental compile. Move the direct subclasses outside of the sealed trait companion object definitely help in our case. But #434 looks scary! :(

[travisbrown]

We've now got docs at least for this issue, via #644.