The diagnostics formatter from swift-syntax previously only handled
fully-formed diagnostics anchored at a particular syntax node.
Therefore, the compiler would fall back to the existing LLVM-based
diagnostic formatter for diagnostics that had no source location.
Adopt new API in the swift-syntax diagnostics formatter that renders a
diagnostic message without requiring source location information, so
that we consistently use the swift-syntax formatter when it is
selected (which is the default).
When a language feature is used inside an `@abi` attribute, we should behave as though it was used on its counterpart. This was already half-implemented—we ensured the counterpart would use the feature—but we didn’t make the ABI decl aware that the counterpart was its parent for feature detection purposes. As a result, we would print `#if` inside the `@abi` attribute, which isn’t valid.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
The decl checker was effectively not being run on these because we weren’t typechecking the PBD and typechecking the VarDecl itself is basically a no-op.
Store specialize witness tables in a separate lookup table in the module. This allows that for a normal conformance there can exist the original _and_ a specialized witness table.
Also, add a boolean property `isSpecialized` to `WitnessTable` which indicates whether the witness table is specialized or not.
Otherwise, we can be inconsistent with isolations returned by other parts of the
code. Previously we were just treating it always as self + nom decl, which is
clearly wrong if a type is not self (e.x.: if it is an isolated parameter).
rdar://135459885
Add a new language feature to avoid the stdlib’s swiftinterface becoming unintelligible to outdated compiler builds due to the generalization of Builtin.is_same_metatype.
rdar://149396721
Don't bind references to storage to use (new ABI) coroutine accessors
unless they're guaranteed to be available. For example, when building
against a resilient module that has coroutine accessors, they can only
be used if the deployment target is >= the version of Swift that
includes the feature.
rdar://148783895
Several callers of `AbstractStorageDecl::getAccessStrategy` only cared
about whether the the access would be via physical storage. Before
adding more arguments to `getAccessStrategy` for which such callers
would have to pass a sentinel value, add a convenience method for this.
The introduction of non-Sendable metatypes in Swift 6.2 (via SE-0470)
will break some existing Swift 6 code. Downgrade concurrency errors
involving non-Sendable metatypes to warnings until some future
language mode to ease the transition.
A metatype for an archetype or existential with no (non-marker)
protocol requirements cannot, by definition, carry any (isolated)
protocol conformances with it, so it's safe to treat such metatypes as
Sendable.
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.
This is going to need a proper implementation in the requirement
machine. For the moment, provide a slightly-less-broken implementation
but leave a test case where we incorrectly accept racey code.
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.
