Only enable experimental features for snapshot and nightly (V2) #11920
Conversation
Also, some refactorings for simplicity.
# Conflicts: # tests/neg-custom-args/no-experimental/experimental.scala
... but not in TastyBootstrap tests
Co-authored-by: Nicolas Stucki <[email protected]>
and some other cleanups
|
What happens for community build? |
|
Community build projects can be configured so that they only run for experimental versions of the compiler. E.g. see scodec. |
|
Several community build projects would not compile under a stable main (this was also true for #11852, I believe). Aside from scodec, there are also: intent, scalap, scas, stdlib123. Also, there are downstream projects that could be affected. We need to decide what the policy should be. I see two choices:
If it's (2), we need more work on the community build to adapt all the tests that would fail otherwise. EDIT: It turns out (1) is not an option right now, since CommunityBuiltTests cannot see the dotc jar, so they cannot patch the variable. |
Instead, use a special exclude if vulpix.ParallelTesting is in the stack trace.
This reverts commit 5d6c42c.
|
Status after trying with simulating a non-snapshot compiler
For DocTest: Look at dotty.communitybuild.projects.scala, value I am reverting here to the standard compiler, but I expect that at least the second problems will resurface once we go to a stable compiler. /cc @abgruszecki @romanowski |
| def checkExperimentalFeature(which: String, srcPos: SrcPos = NoSourcePosition)(using Context) = | ||
| def hasSpecialPermission = | ||
| new Exception().getStackTrace.exists(elem => | ||
| assumeExperimentalIn.exists(elem.getClassName().startsWith(_))) |
There was a problem hiding this comment.
Why would we need this?
There was a problem hiding this comment.
So that we can run the tests from a release compiler
There was a problem hiding this comment.
Why would we want to run tests on experimental features on a release compiler? These cannot be used and there will be a nightly that will cover those tests on that day anyway.
There was a problem hiding this comment.
The tests are there so that we can make sure that the compiler code base can in fact handle the experimental features. There's only one codebase. Those tests can be run from either release or experimental versions. The fact that compilers flag experimental imports as errors unless their version string is a nightly or snapshot is orthogonal to this.
There was a problem hiding this comment.
Note that the previous workaround of experimental subdirectores has been reverted.
Fixes #11774
Mostly based on #11852, but without the requirement that experimental features can only be used by tests in certain directories.
Also, errors are issued when an experimental import or setting is encountered, but the feature is not turned off in that case. It's good enough to have a single error in this case.