The `VersionTuple` API was changed llvm/llvm-project
219672b8dd06c4765185fa3161c98437d49b4a1b to return `VersionTuple`
from `get*Version` rather than pass in major, minor, and subminor output
parameters. Update uses to the new API.
Note that `getMacOSXVersion` is slightly different in that it returns a
boolean while taking a `VersionTuple` output parameter to match its
previous behaviour. There doesn't seem to be any use that actually
checks this value though, so we should either update the API to return
an `Optional` and actually check it *or* remove the "failure" case and
return a `VersionTuple` like all the others.
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
Replace `-warn-concurrency` with a more granular option
`-swift-concurrency=`, where the developer can select one of three
different "modes":
* `off` disables `Sendable` checking for most cases. (This is the Swift
5.5 and Swift 5.6 behavior.)
* `limited` enables `Sendable` checking within code that has adopted
Swift concurrency. (This is currently the default behavior.)
* `on` enables `Sendable` and other concurrency checking throughout
the module. (This is equivalent to `-warn-concurrency` now).
There is currently no distinction between `off` and `limited`. That
will come soon.
Implements the flag part of rdar://91930849.
We add a new flag to disable the implicit import of `_StringProcessing`, similar to `-disable-implicit-concurrency-module-import`. We need this to build `_RegexParser` when `-enable-experimental-string-processing` is enabled by default, because `_StringProcessing` currently imports `_RegexParser` publicly (non-implementation-only).
This flag biases the overload checker in favor of selecting an
asynchronous main function over a synchronous main. If no asynchronous
main function exists, a synchronous one will still be selected.
Likewise, if the flag is not passed and there are only asynchronous main
functions available, the most specific asynchronous main function will
still be selected.
- Add driver and frontend option
- Add LangOptions entry
- Ensure driver propagates flag to frontends
- Add feature to `features.json`
Part of rdar://91119995
Enables SE-0348 `buildPartialBlock` feature by default. The frontend flag is kept for compatibility with existing clients, but is now ineffective.
Also includes some improved error messages for invalid result builder call sites.
Complete support is behind a flag, because it can result in a non-convergent
rewrite system if the opaque result type has a recursive conformance of its
own (eg, `some View` for SwiftUI's View protocol).
Without the flag, it's good enough for simple examples; you just can't have
a requirement that mentions a nested type of a type parameter equated to
the concrete type.
Fixes rdar://problem/88135291, https://bugs.swift.org/browse/SR-15983.
SE-0343 is approved so it's time to pull the feature out from behind the
experimental feature flag. This patch pulls it out and deprecates
passing the flag to the frontend so that we can pull it out entirely
eventually.
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
