Frontend: Allow -enable-experimental-feature to specify upcoming features
#75962
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tshortli
requested review from
hborla,
slavapestov,
xedin and
artemcm
as code owners
tshortli
force-pushed
the
experimental-upcoming-features
branch
2 times, most recently
from
5e7e2d1 to
c015c95
Compare
|
@swift-ci please smoke test |
xedin
approved these changes
Aug 19, 2024
There was a problem hiding this comment.
Makes sense to me! We had a few Issues were people used InferSendableFromCaptures as experimental feature and once we promoted it, that stopped working.
Have you considered adding a warning for this case to nudge people towards use of upcoming instead of keeping it on experimental?
I considered but rejected that idea because I don't want to create a situation where a project owner has an un-addressable warning if they need to support older toolchains that only support the feature as experimental. |
I see, sounds good! |
tshortli
added a commit
to tshortli/swift-package-manager
that referenced
this pull request
Aug 20, 2024
…mportsByDefault`. Both the `StrictConcurrency` and `InternalImportsByDefault` features became "upcoming" features instead of "experimental" features in the Swift 6 compiler. This means that specifying those features with `.enableExperimentalFeature()` no longer works, and therefore these settings in SwiftPM's Package.swift have become inactive. I'm making the compiler more lenient, so that `-enable-experimental-feature` will enable the corresponding upcoming feature if relevant (swiftlang/swift#75962) but in the meantime it appears that some of the code in SwiftPM needs some fixes to continue to be accepted by the compiler with these features on. Additionally, I've removed explicit enablement of `AccessLevelOnImports` since that feature became standard in the Swift 5.10 compiler.
|
Blocked by swiftlang/swift-package-manager#7895. |
tshortli
added a commit
to tshortli/swift-package-manager
that referenced
this pull request
Aug 20, 2024
Both the `StrictConcurrency` and `InternalImportsByDefault` features became "upcoming" features instead of "experimental" features in the Swift 6 compiler. This means that specifying those features with `.enableExperimentalFeature()` no longer works with newer toolchains, and therefore these settings in SwiftPM's Package.swift have become inactive. I'm making the compiler more lenient, so that `-enable-experimental-feature` will enable the corresponding upcoming feature if relevant (swiftlang/swift#75962) but in the meantime it appears that some of the code in SwiftPM needs some fixes to continue to be accepted by the compiler with these features on.
tshortli
added a commit
to swiftlang/swift-package-manager
that referenced
this pull request
Aug 20, 2024
Address some `InternalImportsByDefault` diagnostics in the
`_AsyncFileSystem` which have crept in because the Swift 6 toolchain
isn't enforcing
`.enableExperimentalFeature("InternalImportsByDefault")`.
### Motivation:
Both the `StrictConcurrency` and `InternalImportsByDefault` features
became "upcoming" features instead of "experimental" features in the
Swift 6 compiler. This means that specifying those features with
`.enableExperimentalFeature()` no longer works with newer toolchains,
and therefore these settings in SwiftPM's `Package.swift` have become
inactive. I'm making the compiler more lenient, so that
`-enable-experimental-feature` will enable the corresponding upcoming
feature if relevant (swiftlang/swift#75962) but
in the meantime it appears that some of the code in SwiftPM needs some
fixes to continue to be accepted by the compiler with these features on.
### Modifications:
Adjusted access level on a number of import statements in files
belonging to the `_AsyncFileSystem` target.
### Result:
`_AsyncFileSystem` builds successfully when `InternalImportsByDefault`
is actually enabled with the Swift 6 toolchain.
…ures. During the lifecycle of a feature, it may start as an experimental feature and then graduate to become an upcoming feature. To preserve compatibility with projects that adopted the feature when it was experimental, `-enable-experimental-feature` ought to be able to enable upcoming features, too. Since projects may use `-enable-experimental-feature` for compatibility with an older toolchain that does not have the feature as an upcoming feature, there is no warning when the flag is used to enable an upcoming feature. Note that if the semantics of a feature change when it graduates from experimental to upcoming, then the feature must be renamed so that projects using the experimental feature have an opportunity opt-in to the new semantics of the upcoming feature. Resolves rdar://134276783.
tshortli
force-pushed
the
experimental-upcoming-features
branch
from
c015c95 to
ad1acd7
Compare
|
@swift-ci please smoke test |
|
swiftlang/swift-package-manager#7905 @swift-ci please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During the lifecycle of a feature, it may start as an experimental feature and then graduate to become an upcoming feature. To preserve compatibility with projects that adopted the feature when it was experimental,
-enable-experimental-featureought to be able to enable upcoming features, too.Since projects may use
-enable-experimental-featurefor compatibility with an older toolchain that does not have the feature as an upcoming feature, there is no warning when the flag is used to enable an upcoming feature.Note that if the semantics of a feature change when it graduates from experimental to upcoming, then the feature must be renamed so that projects using the experimental feature have an opportunity opt-in to the new semantics of the upcoming feature.
Resolves rdar://134276783.