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.
(cherry picked from commit 95b18d3482)
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.
(cherry picked from commit 8626404de3)
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)
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.
(cherry picked from commit 92774e0a3c)
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.
Currently, the macro plugin options are included as cache key and the
absolute path of the plugin executable and library will affect cache
hit, even the plugin itself is identical.
Using the new option `-resolved-plugin-validation` flag, the macro
plugin paths are remapped just like the other paths during dependency
scanning. `swift-frontend` will unmap to its original path during the
compilation, make sure the content hasn't changed, and load the plugin.
It also hands few other corner cases for macro plugins:
* Make sure the plugin options in the swift module is prefix mapped.
* Make sure the remarks of the macro loading is not cached, as the
mesasge includes the absolute path of the plugin, and is not
cacheable.
rdar://148465899
(cherry picked from commit 3d38d0dd56)
When type checking a .swiftinterface file, Assume that a mutating methods does
not depend on its parameters. This is unsafe but needed because some
MutableSpan APIs snuck into the standard library interface without specifying
dependencies.
Fixes rdar://148697444 error: a mutating method with a ~Escapable 'self' requires '@lifetime(self:
...)'
(cherry picked from commit a86fe4fa30)
When serializing `@available` attributes, if the attribute applies to a custom
domain include enough information to deserialize the reference to that domain.
Resolves rdar://138441265.
Introduce `PatternBindingCaptureInfoRequest`, and kick it after
contextualizing a property initializer. This ensures it gets run
for stored properties added by macro expansions.
rdar://143429551
Introduce a convenience for aborting while printing a given message
to a frame of the pretty stack trace. Use this in the existing places
where we're currently doing this.
If we're using the macro-specific local discriminator, we need to
make sure we avoid mangling the regular local discriminator in
`appendDeclName`, since that could prematurely kick local discriminator
assignment before type-checking has finished.
rdar://143834482
Unlike in Swift, Obj-C allows method overrides to be declared in extensions
(categories), even outside of the module that defines the type that is being
extended. When MemberImportVisibility is enabled, these overrides must be
filtered out to prevent them from hijacking name lookup and causing the
compiler to insist that the module that defines the extension be imported.
Resolves rdar://145329988.
While here, fix some issues around implied isolated conformances (we
could get into an inconsistent state). Also provide an educational
note discussing isolated conformances and the kinds of errors one can
see when they are used from outside of their isolation domain.
The changes in https://github.com/swiftlang/swift/pull/80040 caused the
compiler to start diagnosing extensions containing only members that are
either `@_spi`, `@_alwaysEmitIntoClient`, or unavailable when the
`-require-explicit-availability` flag is passed. Extensions should not be
diagnosed when they only contain members that would not be diagnosed
themselves.
Resolves rdar://148275432.
