search

scala / scala3

The Scala 3 compiler, also known as Dotty.
https://dotty.epfl.ch
Apache License 2.0
5.83k stars 1.05k forks source link

Release 3.0.0-RC2 #11929

Closed anatoliykmetyuk closed 3 years ago

anatoliykmetyuk commented 3 years ago

Instructions on how to release

smarter commented 3 years ago

When upgrading the scalaVersion in the example projects, I suggest also upgrading to sbt 1.5.0-RC2 and removing sbt-dotty: this way we'll get more people to test that sbt 1.5 works well with scala 3 by default.

japgolly commented 3 years ago

Experimental feature experimental.erasedDefinitions may only be used with nightly or snapshot version of compiler

Oh wow... Wow so we can't use any "experimental" features any more... ok... Can't help but feel like this decision treat users like children who don't understand what "experimental" means. Ultimately it's going to prevent the Dotty team from getting a bunch of early, useful feedback from users trying this stuff out in RCs. Feels like a real shoot-yourself-in-the-foot move.

How are features going to become non-experimental? Take erased classes for example, I would've tested the hell out of them but now will it just be the Dotty team testing it internally, to later remove the experimental status? If so when? What version? 3.0.0? or 3.0.1? Seeing as the announcement isn't out yet, it'd be really useful to clarify how this is going to work out.

smarter commented 3 years ago

Can't help but feel like this decision treat users like children who don't understand what "experimental" means.

And if we allow experimental features in release builds, people complain that experimental is meaningless and we're just recklessly adding features to the language, there's no way to make everyone happy here: https://www.reddit.com/r/scala/comments/m50trg/martin_odersky_explains_the_motivations_behind/gqxj2zv/

How are features going to become non-experimental?

By following the SIP process hopefully.

will it just be the Dotty team testing it internally

No, we very much want people to test these features themselves, we just require that they use a nightly build to do so, given that we provide nightly builds on Maven Central, I don't think this is a tall order, it's also very much inspired by the way Rust does thing which seems to have worked well for them so far.

If so when? What version?

Depends on when/if the feature is accepted by the SIP committee and the community.

SethTisue commented 3 years ago

I strongly support this change. But I would like to add:

Historically, it has been rather difficult to use Scala 2 nightlies on some codebases, namely if there are dependencies, perhaps transitive ones, that are fully cross-versioned (as opposed to only by major version): so e.g. kind-projector, Scalameta. I've struggled with this myself, even though I'm pretty well versed in sbt. In simple cases I'm sometimes able to resolve it adding an override or by publishing a dependency locally, but sometimes it gets tricky. (In other cases I use dbuild, but I'm almost the only person for whom that's a reasonable solution.)

I assume users might run into comparable difficulties in testing Scala 3 nightlies with their codebases. If so, it remains a build tool issue and not a language issue, but: I believe this change will put some pressure on build tool maintainers to make nightlies convenient to use on more projects. Whether it's through documentation, or actual changes to the tool, or both. (Typically sbt leads on these sorts of issues and then the other tools try to catch up.)

/cc @eed3si9n

smarter commented 3 years ago

I'm not sure what build tool issue you have in mind, if you're using a project whose cross-version is the full compiler version, that means it relies on APIs which might change between every version, so you can't expect it to work with a nightly. If you're feeling brave you can always try replacing "foo" %%% "bla" by "foo_specificversion" % "bla" in your build, but a build tool shouldn't do that for you automatically since there's no guarantee it will work. (I'd say the real solution here is: don't use compiler plugins, implement your changes in the actual compiler instead!).

SethTisue commented 3 years ago

so you can't expect it to work with a nightly

It might not, but often it does; and if it does, it's a win because now I can test something I couldn't have otherwise tested.

If you're feeling brave you can always try replacing "foo" %%% "bla" by "foo_specificversion" % "bla" in your build

in my experience it's often not that simple, because of transitive dependencies

anatoliykmetyuk commented 3 years ago

When upgrading the scalaVersion in the example projects, I suggest also upgrading to sbt 1.5.0-RC2 and removing sbt-dotty: this way we'll get more people to test that sbt 1.5 works well with scala 3 by default.

Getting errors like:

    useScala3doc := true,
    ^
sbt.compiler.EvalException: Type error in expression

And

lazy val crossVersions = Seq(Option(rcVersion), dottyLatestNightlyBuild()).flatten
                                                ^
sbt.compiler.EvalException: Type error in expression

I set sbt.version=1.5.0-RC2 in project/build.properties and removed the SBT Dotty plugin on scala3-example-project. Any ideas on how to migrate those settings?

eed3si9n commented 3 years ago 
scala3-example-project/build.sbt:2: error: not found: value dottyLatestNightlyBuild
lazy val crossVersions = Seq(Option(rcVersion), dottyLatestNightlyBuild()).flatten
                                                ^
scala3-example-project/build.sbt:11: error: not found: value useScala3doc
    useScala3doc := true,
    ^
sbt.compiler.EvalException: Type error in expression
[error] sbt.compiler.EvalException: Type error in expression
[error] Use 'last' for the full log.
[warn] Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? (default: r)

It says the values are not found, so maybe the feature was dropped? Could you open an issue under sbt/sbt? We can continue the discussion there.

smarter commented 3 years ago

@anatoliykmetyuk you should just remove the useScala3doc setting, it's no longer needed.

smarter commented 3 years ago

Oh and dottyLatestNightlyBuild doesn't exist in sbt either and should be removed from the example project (I don't think it should have ever been added, this is supposed to be a simple example you can copy-paste, it shouldn't include more advanced things like cross-compilation)

anatoliykmetyuk commented 3 years ago

Is the removal of these settings issue-worthy at sbt/sbt?

smarter commented 3 years ago

No, not adding these settings was intentional

japgolly commented 3 years ago

No, we very much want people to test these features themselves, we just require that they use a nightly build to do

Well in that case I'd be happy to help test the new features. I was already looking forward to anyway. The problem is it seems near impossible for me to do so because I'm not working on a dependency-free project, I'm working on a chain of libraries that depend on each other and I'm depending on other libraries that've been published for RC1 (and soon RC2) proper. I spent a limited amount of time trying to make that work and failed. If using nighties is going to become a more common practice then can we get some documentation on how to configure sbt? Ideally it would be alongside the RC2 release notes because this is the first release to force people on to nightlies, and I imagine many others are going to struggle with how to setup sbt to mix-and-match all different versions.

japgolly commented 3 years ago

Also FYI there's no nightly out that includes everything in RC2. The latest is 3.0.0-RC2-bin-20210328-cca5f8f-NIGHTLY which is a bunch of commits behind 3.0.0-RC2. A 20210329 nightly should've been out by now; maybe someone in the know can check?

smarter commented 3 years ago

can we get some documentation on how to configure sbt?

To use a nighty, you just need to set the scalaVersion to that nightly version, no extra setup required since we publish nightlies on maven, it's also documented in https://github.com/scala/scala3-example-project

A 20210329 nightly should've been out by now

Now that RC2 is out, no more nightlies for it will be published, the next nightly will be for 3.0.1-RC1 but the one from last night failed because of https://github.com/lampepfl/dotty/pull/11946

nafg commented 3 years ago

Except if it doesn't fit with Scala 3's restrictions, like @Lenses (from Monocle)

By the way does that mean that to have code coverage in Scala 3 it will be added to the compiler? What about other instrumentation, like scalac-profiler (if I remember the name right)?

On Tue, Mar 30, 2021, 1:15 PM Guillaume Martres @.***> wrote:

I'm not sure what build tool issue you have in mind, if you're using a project whose cross-version is the full compiler version, that means it relies on APIs which might change between every version, so you can't expect it to work with a nightly. If you're feeling brave you can always try replacing "foo" %%% "bla" by "foo_specificversion" % "bla" in your build, but a build tool shouldn't do that for you automatically since there's no guarantee it will work. (I'd say the real solution here is: don't use compiler plugins, implement your changes in the actual compiler instead!).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lampepfl/dotty/issues/11929#issuecomment-810433935, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYAUGGV4RU5NMDE3ZMTQTTGIBJNANCNFSM4Z7PXN2A .

smarter commented 3 years ago

By the way does that mean that to have code coverage in Scala 3 it will be added to the compiler?

That would be for the best I think yes, there's already a prototype of that, but it needs someone to finish it: http://guillaume.martres.me/code_coverage.pdf

scalac-profiler

https://github.com/scalacenter/scalac-profiling appears to be abandoned, but yeah more profiling built into the compiler could be useful.

japgolly commented 3 years ago

@smarter A few follow up questions if you don't mind

Now that RC2 is out, no more nightlies for it will be published, the next nightly will be for 3.0.1-RC1

How are we supposed to test the experimental features in RC2? The latest RC2 nightly is 3.0.0-RC2-bin-20210328-cca5f8f-NIGHTLY which is a significant number of commits behind the final RC2. The next available nightly is 3.0.1-RC1-bin-20210330-3ebeaa9-NIGHTLY which, please correct me if I'm wrong, can't be used with any RC2 artifact for the same reasons that I can't use any RC1 stuff when I'm on RC2.

So RC2 has experimental features... They can only be tested on nightly builds... There's no nightly build that follows RC2... The next nightly build is incompatible with RC2... I think this is an impossible situation.

To use a nighty, you just need to set the scalaVersion to that nightly version, no extra setup required

Either you didn't understand what I was saying about dependency chains, or I'm not understanding the situation properly. If I change library A to depend on a nightly of RC2, great, that's easy enough. Now I publish that library and move on to library B which depends on library A, what's the compatibility story like? Do I have to use the exact same nightly version in library B as is used in library A? Will any RC2 build be compatible? If I use non-nightly RC2 in lib B are we expecting that to work?

If I have to start using 3.0.1-RC1 nightlies to test the experimental features in RC2, do all downstream libraries now need to use 3.0.1-RC1 as well?

Do you see what I mean? I don't understand how anyone can test the experimental stuff in RC2.

smarter commented 3 years ago

The next available nightly is 3.0.1-RC1-bin-20210330-3ebeaa9-NIGHTLY which, please correct me if I'm wrong, can't be used with any RC2 artifact for the same reasons that I can't use any RC1 stuff when I'm on RC2.

Yeah, that's an issue for now that will be resolved after 3.0.0 is out and all suffixes are _3 (this should already be the case for nightlies right now but isn't due to https://github.com/lampepfl/dotty/pull/11952)

Now I publish that library and move on to library B which depends on library A, what's the compatibility story like?

It's going to depend on the tasty version of the compilers involved, but I would recommend using the same nightly for the whole chain and we might end up enforcing that depending on a nightly-compiled artefact requires using a nightly compiler since otherwise one might accidentally transitively depend on experimental features without realizing it, but this is still all up in the air.

japgolly commented 3 years ago

Yeah ok cool thanks @smarter . The code I write tends to find lots of bugs pretty quickly so I was hoping to test erased-defs early and get it stable asap (because it's one of the most exciting features for me) but unfortunately I think I'll just hold off for a while, until it gets easier. Even updating and republishing everything for RC2 is proving to be a bit of a pain :( Really looking forward to those stable _3 suffixes.