New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SE-0362 "upcoming features" are treated as "unsafe flags" #5965
Comments
It's not at all clear to me how to fix this. The flags are added to OTHER_SWIFT_FLAGS, which seems appropriate on the surface, but then any flag in OTHER_SWIFT_FLAGS is treated as unsafe. So the obvious way to avoid this is to introduce another |
@DougGregor what do you think? |
Yah, I don't think that is intentional, as you say, the entire point would be to not have to resort to unsafe flags for these. |
The intent is that "upcoming" and "experimental" features are not treated as unsafe flags. I hadn't realized the link to |
BTW, only SwiftPM's XCBuild support should be using |
It's completely general; my original report is from Linux. The |
Oh yah, you're right. I think the way |
From my very limited poking around in the source, that seems a more reasonable approach that will also prevent issues like this one from recurring as more safe |
Currently, we are diagnosing unsafe flags in a bit of a backwards way, trying to infer them from build settings that were derived from them. This adds an explicit `usesUnsafeFlags` model property that is driven by whether the `unsafeFlags` API was used in a given target. fixes #5965
Currently, we are diagnosing unsafe flags in a bit of a backwards way, trying to infer them from build settings that were derived from them. This adds an explicit `usesUnsafeFlags` model property that is driven by whether the `unsafeFlags` API was used in a given target. fixes #5965
Currently, we are diagnosing unsafe flags in a bit of a backwards way, trying to infer them from build settings that were derived from them. This adds an explicit `usesUnsafeFlags` model property that is driven by whether the `unsafeFlags` API was used in a given target. fixes #5965
Currently, we are diagnosing unsafe flags in a bit of a backwards way, trying to infer them from build settings that were derived from them. This adds an explicit `usesUnsafeFlags` model property that is driven by whether the `unsafeFlags` API was used in a given target. fixes #5965 (cherry picked from commit a227ff0)
Currently, we are diagnosing unsafe flags in a bit of a backwards way, trying to infer them from build settings that were derived from them. This adds an explicit `usesUnsafeFlags` model property that is driven by whether the `unsafeFlags` API was used in a given target. fixes #5965 (cherry picked from commit a227ff0)
Description
When using SE-0362's
upcomingFeatures
, a package becomes ineligible for use as a dependency.This isn't explicitly called out in the evolution proposal, but I believe it runs contrary to the intent. After all, what use is the ability to enable (eg) bare slash regular expressions for my own convenience, if nobody can use my library because of it?
Expected behavior
upcomingFeatures
should not be treated as "unsafe", and other packages should be able to depend on my package if I use these (experimental features is much more of a gray area, and might require deeper consideration!)Steps to reproduce
Here's a failing test you can add to
PackageGraphTests.swift
:Swift Package Manager version/commit hash
dd7e9cc
Swift & OS version (output of
swift --version && uname -a
)Swift version 5.7 (swift-5.7-RELEASE)
Target: x86_64-unknown-linux-gnu
Linux GGPC 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: