Enable the feature by default, and add an experimental feature
`DeprecateCompatMemberwiseInit` to control the deprecation behavior
which was deferred from the proposal.
A protocol that's been reparented declares it
by writing `@reparented` in its inheirtance clause
for each new parent. You can introduce a `@reparented`
parent to a pre-existing ABI-stable protocol's
inheritance hierarchy.
Only protocols declared to be `@reparentable` can be
used to reparent other protocols. Adding or removing
the `@reparentable` attribute is ABI-breaking, as it
effects the type metadata layout. Thus, reparentable
protocols must be born as such to use them with
protocols that are already ABI-stable.
This set of changes does not include the actual
implementation of ABI-stable reparenting.
This optimizes for the case where we have a disjunction that contains an
operator defined in a protocol, and a protocol defined in a protocol
extension, and furthermore, the protocol extension operator's type is a
refinement of the protocol requirement operator's type.
In this case, there are three possibilities:
- Either the operator requirement is witnessed by a concrete operator
in the conforming type, in which case the solution involving the
protocol extension operator is going to be worse, so we can skip this
choice.
- Otherwise, the protocol requirement operator is witnessed by the same
protocol extension operator that we skipped, in which case we will find
the same solution if we just pick the protocol requirement operator
anyway.
- The only other possibility is that the protocol requirement operator
is witnessed by a protocol extension operator, but also, a more
refined protocol extension operator exists. However, it appears that in
this case, solution ranking _also_ picks the solution involving the
protocol requirement operator, as the new test case demonstrates.
Thus, we gain nothing by considering these protocol extension operators.
Skip them when forming the disjunction.
In the context of coroutine/yielding accessors, "unwind" means
that the second half of the coroutine (code _after_ the `yield`
statement) will not run if an exception is thrown during the access.
Unwinding was the default behavor for legacy `_read`/`_modify` coroutine
accessors.
For the new `yielding borrow`/`yielding mutate` accessors, unwinding
was optional behind a separate feature flag.
But the final SE-0474 dictates that unwinding is always _disabled_ for
the new yielding accessors. That is, the new yielding accessors always
run to completion, regardless of whether there are thrown exceptions within
the access scope. This was deemed essential to ensure that authors of
data structures could guarantee consistency.
This PR permanently disables unwinding behavior for the new accessors.
The feature flag still exists but has no effect.
A handful of tests that verified the unwinding behavior have been
edited to ensure that unwinding does _not_ happen even when the feature
flag is specified.
We need to stage in the behavior change to enable dynamic exclusivity
checking for Embedded Swift. For now, ignore
`-enforce-exclusivity=checked` in Embedded Swift unless the
experimental feature `EmbeddedDynamicExclusivity` is also enabled.
Addresses rdar://168618037, a regression in Embedded Swift code that
is passing `-enforce-exclusivity=checked` explicitly.
For now, we write `read`/`modify` to .swiftinterface files
so they can be read by the draft implementation in current
compilers. Here are some of the issues:
* We _cannot_ support `read`/`modify` in Swift sources without
the user specifying a flag. That's because the idiom below occurs
in real code, and would be broken by such support. So when
we enable the `CoroutineAccessors` flag by default, we _must_
not support `read`/`modify` as accessor notations in source.
```
struct XYZ {
// `read` method that takes a closure
func read(_ closure: () -> ()) { ... }
// getter that uses the above closure
var foo: Type {
read { ... closure ... }
}
}
```
* .swiftinterface files don't have the above problem.
Accessor bodies aren't stored at all by default, and
when inlineable, we always write explicit `get`.
So we can continue to accept `read`/`modify` notation
in interface files.
So our strategy here is:
* We'll accept both `read`/`modify` and `yielding borrow`/`yielding mutate`
in interface files for a lengthy transition period.
* We'll write `read`/`modify` to swiftinterface files for
a little longer, then switch to `yielding borrow`/`yielding mutate`.
* We'll disable `read`/`modify` support in source files
when we enable `CoroutineAccessors` by default.
(We can't even diagnose, due to the above idiom.)
This means that early adopters will have to update their sources
to use the new terminology. However, swiftinterface files
will be exchangeable between the new and old compilers for a little
while.
LLVM is switching to use these APIs instead of report_fatal_error. One
unfortunate characteristic of these APIs is that they take Twines and StringRefs
so if one wants to use a type that uses raw_ostream based print APIs, one has to
by hand create a SmallString, create an ostream to put the value into the
SmallString and then call the API. These helpers just perform that initial bit
of work of creating the SmallString and ostream and pass in the ostream to the
callback. After the callback returns, we pass the SmallString to
reportFatal{Internal,Usage}Error.
I also imported the llvm APIs into the swift namespace as well.
This experimental feature allows you to override the default behavior
of a 'get' returning a noncopyable type, so that it returns an owned
value rather than a borrow, when that getter is exposed in opaque
interfaces like protocol requirements or resilient types.
resolves rdar://157318147
This prevents stuff like memcmp from SwiftShims from being imported with
@_SwiftifyImport, which would then result in name lookup errors as it
does not import the Swift standard library module. This makes the
previous approach to disable safe interop when compiling with
-parse-stdlib redundant.
irdar://165856959
Some access control holes were unconditionally downgraded to warnings, and
others were conditional on Swift 6 language mode. Let's hang them off an
upcoming feature instead.
Otherwise these source file objects linger in the source manager but they refer to a fully-temporary 'ASTContext' which does not exist after parsing is complete, which means they cannot be used in any way and attempting to do so would lead to a crash.
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
