The IsolatedConformances feature moves to a normal, supported feature.
Remove all of the experimental-feature flags on test cases and such.
The InferIsolatedConformances feature moves to an upcoming feature for
Swift 7. This should become an adoptable feature, adding "nonisolated"
where needed.
(cherry picked from commit 3380331e7e)
Potential unavailability of a declaration has always been diagnosed in contexts
that do not have a sufficient platform introduction constraint, even when those
contexts are also unavailable on the target platform. This behavior is overly
strict, since the potential unavailability will never matter, but it's a
longstanding quirk of availability checking. As a result, some source code has
been written to work around this quirk by marking declarations as
simultaneously unavailable and introduced for a given platform:
```
@available(macOS, unavailable, introduced: 15)
func unavailableAndIntroducedInMacOS15() {
// ... allowed to call functions introduced in macOS 15.
}
```
When availability checking was refactored to be based on a constraint engine in
https://github.com/swiftlang/swift/pull/79260, the compiler started effectively
treating `@available(macOS, unavailable, introduced: 15)` as just
`@available(macOS, unavailable)` because the introduction constraint was
treated as lower priority and therefore superseded by the unavailability
constraint. This caused a regression for the code that was written to work
around the availability checker's strictness.
We could try to match the behavior from previous releases, but it's actually
tricky to match the behavior well enough in the new availability checking
architecture to fully fix source compatibility. Consequently, it seems like the
best fix is actually to address this long standing issue and stop diagnosing
potential unavailability in unavailable contexts. The main risk of this
approach is source compatibility for regions of unavailable code. It's
theoretically possible that restricting available declarations by introduction
version in unavailable contexts is important to prevent ambiguities during
overload resolution in some codebases. If we find that is a problem that is too
prevalent, we may have to take a different approach.
Resolves rdar://147945883.
Initializers should always have Swift names that have the special `DeclBaseName::createConstructor()` base name. Although there is an assertion to this effect in the constructor for ConstructorDecl, ClangImporter did not actually reject custom Swift names for initializers that violated this rule. This meant that asserts compilers would crash if they encountered code with an invalid `swift_name` attribute, while release compilers would silently accept them (while excluding these decls from certain checks since lookups that were supposed to find all initializers didn’t find them).
Modify ClangImporter to diagnose this condition and ignore the custom Swift name.
The check to see whether argument matches the parameter exactly
causes two problems: prevents projected value initialized injection;
and, if there are multiple parameters with property wrappers,
would apply incorrect wrapper to other locations because the wrapper
application index wasn't incremented.
Resolves: rdar://140282980
To maintain source compatibility, SE-0352 does not open existentials
with "self-conforming" type, such as `any Error` or existentials based
on `@objc` protocols. The proposal specified that this behavior would
change in Swift 6. Implement that behavior change, which can be
enabled prior to Swift 6 with the upcoming feature
`ImplicitOpenExistentials` (as documented in SE-0362).
Fixes#70873 / rdar://120902975.
Don't delete the OS declaration of `exit` because the concurrency shims aren't always imported, and so the shim declaration might not always be available.
Don't override the OS declaration of `exit` in the concurrency shims since we can't just delete the OS one. Instead, set up internal shims just for building Concurrency that forward declares `exit`.
