Compile the stdlib with Dotty as part of the CI #7800
Conversation
smarter
force-pushed
the
dotty-ci
branch
2 times, most recently
from
72362e7 to
02a57e7
Compare
|
The CI errors appear to be unrelated to this PR:
|
|
CI failure is spurious (scala/scala-dev#617) |
It was previously annotated with `@deprecatedInheritance` along with a bunch of other annotations in 6e4d00e to make upgrades smoother, but Dotty does not and is not planning to support annotating a type with itself, and this is the last remaining issue to compile the standard library with Dotty without any modification, so just mark it `final` since I doubt extending this annotation was a common occurence anyway.
When sbt is started with `-Dscala.build.compileWithDotty=true`, Dotty will be used as the STARR (this is toggled by a property to avoid any interference between sbt-dotty and the regular build). Using this, we add compilation of the standard library using Dotty to the CI, to make sure it's never unintentionally broken.
eed3si9n
left a comment
eed3si9n
left a comment
There was a problem hiding this comment.
overall LGTM with a minor suggestion.
|
you modified the Travis build, but I suggest the same change should be made in the Jenkins one in the we do have designs to fully switch from Jenkins to Travis, but we're not there yet. I'd say that the Jenkins one is the "real" one and the Travis one is still a somewhat experimental alternative. (and, we're a bit nervous about the future of Travis, since its ownership has changed hands...) |
|
also, I am vaguely paranoid that the classfiles generated could end up being used downstream somehow. how sure are you that isn't an issue? (if not that sure, should it use an alternate target directory?) |
Not sure what you mean, downstream of what ?
The classfiles end up in |
👍 , then (by downstream, I meant some later CI step (perhaps one that doesn't exist yet)) |
|
Ah I see, I think the best way to avoid that is to leave the Dotty stuff at the very end of the stuff executed by the ci. |
Avoid unexpected class casts due to potential misuse in subclasses of the following cunning trick, which allowed for centralized implementation of common factory methods, assuming the right overrides are provided in subclasses: `protected type IterableCC[X] = CC[X] @uncheckedVariance` Risk of not overriding correctly illustrated by https://gist.github.com/lrytz/fe09791208969f07e211c5c8601db125. It's basically an encoding of MyType, which is only sound under pretty severe restrictions, which are not enforced by the compiler. Instead, we mix in a default implementation of the various factory methods whenever we are in a trait where the collection's type is known (and of the regular shape CC[A] or MapCC[K, V]). It would be nice if we could conditionally mix in this trait into the *Ops traits whenever `C =:= CC[A]`, but we don't have that kind of inheritance (private inheritance would be nice too, I guess, since the `*FactoryDefaults` traits don't really add much utility to the public signature of these collection classes). While we're at it, also add an `empty` method at the top of the hierarchy to facilitate the switch to dotty's for comprehensions (since we want the stdlibs between Scala 2 & 3 to be the same, and 2.14 will try to only make backwards compatible changes from 2.13). Motivated by the intersection of scala#7458, scala#7929, scala#7800 (better refchecks and compiling with dotc revealed part of the problem) 🤯 Co-authored-by: Lukas Rytz <[email protected]>
6 participants
As suggested by @adriaanm at some point.
When sbt is started with
-Dscala.build.compileWithDotty=true, Dottywill be used as the STARR (this is toggled by a property to avoid any
interference between sbt-dotty and the regular build). Using this,
we add compilation of the standard library using Dotty to the CI,
to make sure it's never unintentionally broken.