Fixes a build problem when using a mainline compiler with a 6.2 Swift.swiftinterface file.
This was caused by mistakenly cherry-picking the `#if $AddressOfProperty` conditions in the stdlib into 6.2 without the required compiler change.
This unblocks the CI while we figure out some SILGen issues. We cannot
reuse AddressableParameters because that is already used in some
projects and consuming modules where the AddressableParameters flag was not
propagated to results in deserialization errors.
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
This patch re-enables diagnostics for unannotated C++ functions or
methods returning `SWIFT_SHARED_REFERENCE` types. These warnings now
fire only **once per source location**, even in the presence of multiple
template instantiations. This avoids diagnostic duplication that was a
key source of noise in the compilation of larger codebases.
These warnings were previously disabled starting in **Swift 6.2** via
[PR-#81411](https://github.com/swiftlang/swift/pull/81411) due to
concerns around false positives and excessive duplication in projects
adopting C++ interop. This patch addresses the duplication issue by
adding source-location-based caching, which ensures that a warning is
emitted only once per source location, even across template
instantiations with different types.
However, the false positive issue remains to be investigated and will be
addressed in a follow-up patch. Until that happens, the warnings are
gated behind a new experimental feature flag:
`WarnUnannotatedReturnOfCxxFrt`. This feature will be enabled by default
only after thorough qualification and testing on large C++ codebases.
rdar://154261051
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
When the default isolation is main-actor, don't infer @MainActor
for a type that conforms to a protocol P in its primary definition when
P inherits from Sendable. Such types should remain non-isolated
because they're highly unlikely to be able to implement the P
conformance (which cannot be isolated).
Put this feature behind a new experimental flag,
SendableProhibitsMainActorInference.
Implements rdar://151029300
This flag was not experimental for any good reason; it should always be
enabled. The flag only exists so we can introduce a new API:
UnsafeMutablePointer.mutableSpan. Supported compilers cannot handle the new API.
rdar://154247502 (Promote feature NonescapableAccessorOnTrivial to be
non-experimental)
To guard the new UnsafeMutablePointer.mutableSpan APIs.
This allows older compilers to ignore the new APIs. Otherwise, the type checker
will crash on the synthesized _read accessor for a non-Escapable type:
error: cannot infer lifetime dependence on the '_read' accessor because 'self'
is BitwiseCopyable, specify '@lifetime(borrow self)'
I don't know why the _read is synthesized in these cases, but apparently it's
always been that way.
Fixes: rdar://153773093 ([nonescapable] add a compiler feature to guard
~Escapable accessors when self is trivial)
We want to be able to adopt
(https://github.com/swiftlang/swift/pull/82225) in the stdlib without
breaking people building at desk with older toolchains, so let's add a
feature flag.
Ideally we'd be able to use the llvm interleave2 and deinterleave2
intrinsics instead of adding these, but deinterleave currently isn't
available from Swift, and even if you hack that in, the codegen from
LLVM is worse than what shufflevector produces for both x86 and arm. So
in the medium-term we'll use these builtins, and hope to remove them in
favor of [de]interleave2 at some future point.
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
When migrating, provide warnings that add 'nonisolated' to nonisolated
conformances that don't already have it and would end up being inferred
to be isolated under the upcoming feature.
Syntactically verify that initializer expressions of '@const' variables and argument expressions to '@const' parameters consist strictly of syntactically-verifiable set of basic values and operations
This includes changing the feature name so that compilers with the experimental feature don’t accidentally pick up content that only works in the final version.
Resolves rdar://150065196.
Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
Guard against condfails when older compilers get a swift interface
that uses `@extensible` attribute. The attribute itself doesn't
have any effect in swift interfaces yet since all of the public
enums are already resilient in that mode.
