extension Array where Element == SwiftSetting {
static var concurrencyChecking: [SwiftSetting] {
if Context.environment["ENABLE_STRICT_CONCURRENCY"] != nil {
return [SwiftSetting.unsafeFlags(["-Xfrontend", "-strict-concurrency=complete"])]
} else {
return []
}
}
}
Setting an environment variable in the shell and building with % swift build activates the unsafeFlags while builds via Xcode does not.
This works great for enabling concurrency checking via build scripts (CI) but is there any way to enable this checking within Xcode for developers performing local edits?
Interestingly this doesn't seem to work for me. Using .enableUpcomingFeature("StrictConcurrency"), in a target in my Package file doesn't show any warnings, but using .unsafeFlags(["-Xfrontend", "-warn-concurrency"]) does show a bunch.
With Xcode Version 14.3 (14E222b) and Swift version 5.8.
Same here: .enableUpcomingFeature("StrictConcurrency") doesn't show any warnings for me, whereas .unsafeFlags(["-Xfrontend", "-warn-concurrency"]) or .unsafeFlags(["-Xfrontend", "-strict-concurrency=complete"]) does show warnings.
If I'm reading the compiler source code correctly, it cannot work because StrictConcurrency is not defined as an upcoming feature flag at all.
I believe this thread is conflating prerelease feature flags (flags in the compiler while a feature is under development) and upcoming feature flags (features which will be enabled in a future version of Swift, usually 6). Upcoming features with flags are flagged because they may include source breakages or are otherwise large changes. I believe the proposal which formalized such flags didn't do a great job of differentiating between the two use cases, so it's not clear when proposals use one type of flag or the other. But that's likely the case here.
I don't think we're conflating these. If you follow the links to Features.def I posted above, the file distinguishes between UPCOMING_FEATURE and EXPERIMENTAL_FEATURE. We're only talking about the former. SE-0362 lists 6 upcoming features. These are all non-experimental features that went through Swift Evolution.
For whatever reason, only 4 of those 6 upcoming features have working feature flags in Swift 5.8. To be fair, this matches with what's documented in the Swift 5.8 intro blog post on swift.org (as far as I can tell, the changelog on GitHub only lists 3 of the 4 features).
I can't speak to ImplicitOpenExistentials (maybe the semantics change mentioned in SE-0362 isn't implemented yet?), but for StrictConcurrency this seems like an oversight because we know for a fact that a flag for strict concurrency checking exists, it just doesn't seem to be working with the new feature flag mechanism.
Is that true? For remote dependencies you don't want this enabled, as it just produces diagnostics you can't fix. For local development dependencies you can use the unsafe flag version, as SPM doesn't care if you use those in unversioned dependencies (IIRC).
The evolution proposals with upcoming feature flags have all been updated with an Upcoming Feature Flag field and a description of what it does in the Source Compatibility section of the proposal.
I don't know why the StrictConcurrency flag was not added, but I was guessing it may be because the existing -strict-concurrency compiler flag can either be set to either targeted or complete so has more functionality than a simple on/off flag.
FYI, on the Swift Evolution dashboard, upcoming feature flags are now displayed for proposals that have one and can be searched for by name. There is currently a PR to add a filter to show proposals with an upcoming feature flag.
Well, we use versioning extensively internally and have a case to systematically turn on swift 6 flags (especially concurrency checking) across a wide range of versioned repos. Some might be open source as well and it’d be nice to turn these checks on in a systemic manner. Maybe I’m missing something but that’s our thoughts.