Fix #11774: only enable experimental features for snapshot and nightly

[liufengyun]

Fix #11774: only enable experimental features for snapshot and nightly

[nicolasstucki]

@liufengyun rebasing on #11845 should fix the issues of erasedValue.

[liufengyun]

Maybe we should refine the message by saying that Scala 3 macros are not experimental.

[sjrd]

Using a negative flag rather than a positive means that we'll have a lot more work to do to make sure everything works as expected:

• Add -Yno-experimental in the bootstrap build of the compiler, library, and any other non-test project. Otherwise, we may (and will) miss usage of experimental features that will only pop up at the time of the release, or worse, when trying to re-bootstrap.
• Adding -Yno-experimental should be the default for almost all tests. Only the tests that use experimental features should not have the flag. Otherwise, again, you may discover that the test suite fails for release builds even though it worked fine before.
• The (relatively rare) tests that do use experimental features need to be somehow excluded from the CI for release builds.

[liufengyun]

@sjrd That makes sense. However, for end-users, asking for both language import and -Yenable-experimental seems to be too much.

[liufengyun]

• It's weird that the compiler version for community build is version (unknown):

https://github.com/lampepfl/dotty/runs/2176107889#step:7:798

Edit: Fixed in 182861b.

[smarter]

/cc @mpilquist: This PR prevents experimental language features from being used with non-nightly compiler builds (following the rust model and to avoid repeating the situation where scala.experimental.macros became de-facto non-experimental), but currently scodec relies on -language:experimental.genericNumberLiterals so it will require a nightly compiler once this PR is merged.

[mpilquist]

Thanks for the heads up. I guess this means scodec should remove the FromDigits.WithRadix instances until that feature is considered non-experimental?

[smarter]

Right, and I guess these instances could also be provided in a separate project for testing purposes if needed.

[mpilquist]

@smarter I can keep the FromDigits.WithRadix instances in scodec-bits after all, since scala.util.FromDigits will still be in the standard library and the instances themselves don't require this flag. They just don't serve much purpose in that folks can't use them as intended. Right?

It seems a bit strange that the FromDigits type will be in 3.0.0 final but unusable due to being experimental.

[smarter]

That should work yes, and I agree but we don't have a mechanism to mark APIs themselves as experimental currently (Java has @jdk.internal.javac.PreviewFeature https://openjdk.java.net/jeps/12)

[mpilquist]

OK, I commented out for now. These commits or after should work for community build:

• scodec-bits: scodec/scodec-bits@76891c2
• scodec: scodec/scodec@fe84424

[liufengyun]

@mpilquist It seems the upstream and the community build have diverged:

The latest commits in the community build:

• scodec: https://github.com/dotty-staging/scodec/commits/move-compiletime-S
• scodec-bits: https://github.com/dotty-staging/scodec-bits/commits/update-lifting-api

We can find a way to sync the upstream and the community build (in another PR).

[liufengyun]

@odersky FYI, putting fewerBraces under experimental means that it will only available for nightly build of compilers after this PR. Normal releases cannot use the feature.

[odersky]

Yes, that's understood.