[PR-84375](https://github.com/swiftlang/swift/pull/84375/) mistakenly
added a typo to the message of the
`returns_retained_or_returns_unretained_for_non_cxx_frt_values`
diagnostic just before merging. Fixing that typo in this patch.
For non-generic cases we can simply recurse into the underlying type,
ensuring we don't crash with a null GenericSignature. For generic
cases, ensure we bind outer generic parameters to their archetypes,
and apply the substitutions to the original underlying type to ensure
we correctly handle cases where e.g an unbound generic is passed as
a generic argument to a generic typealias.
rdar://160135085
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
Some foreign reference types such as IUnknown define retain/release operations as methods of the type.
Previously Swift only supported retain/release operations as standalone functions.
The syntax for member functions would be `SWIFT_SHARED_REFERENCE(.doRetain, .doRelease)`.
rdar://160696723
It's very, very easy to make a mistake that will cause broken
serialized modules. Until that's no longer true, at least tell folks
that they are heading into uncharted waters, as we do with
`@_implementationOnly` imports.
When using an internal import for a bridging header, semantically treat
the contents of the bridging header, and anything that it imports, as
if they were imported internally. This is the actual semantic behavior
we wanted from internally-imported bridging headers.
This is the main semantic checking bit for rdar://74011750.
The flags "-import-bridging-header" and "-import-pch" import a bridging
header, treating the contents as a public import. Introduce
"internal-" variants of both flags that provide the same semantics,
but are intended to treat the imported contents as if they came in
through an internal import. This is just plumbing of the options for
the moment.
This does not enable it by default. Use either of the flags:
```
-enable-copy-propagation
-enable-copy-propagation=always
```
to enable it in -Onone. The previous frontend flag
`-enable-copy-propagation=true` has been renamed to
`-enable-copy-propagation=optimizing`, which is currently default.
rdar://107610971
When importing C++ template classes like`Ref<T>` that have methods
returning `T*`, we face the following situation when `T` is a
`SWIFT_SHARED_REFERENCE` type:
1. Without `SWIFT_RETURNS_(UN)RETAINED` annotation: Swift compiler would
emit a warning (currently under experimental-feature flag
`WarnUnannotatedReturnOfCxxFrt`) _"cannot infer the ownership of the
returned value" when T is a SWIFT_SHARED_REFERENCE type_
2. With annotation: Compiler rejects it with this error: _"cannot be
annotated... not returning a SWIFT_SHARED_REFERENCE type"_
This affects WebGPU's smart pointer types (`WTF::Ref<T>,
WTF::RefPtr<T>`) and similar patterns in other C++ codebases.
In this patch I am fixing the logic for diagnostic
`returns_retained_or_returns_unretained_for_non_cxx_frt_values`. I'm
also making it a warning instead of an error to minimize the risk, as
this diagnostic has been a hindrance to the adoption of these
annotations in real codebases when templated functions and types are
involved. (Refer to
[PR-78968](https://github.com/swiftlang/swift/pull/78968))
rdar://160862498
Not all clients can properly handle the presence of placeholders in
interface types and it doesn't seem worth the complexity for the
type replacement diagnostic.
Embedded Swift doesn't have protocol conformance metadata, so it cannot
handle dynamic casts to existentials (nor should it).
Another part of rdar://119383905.
The existing SIL-level diagnostic for this check only triggers when
the type is actually used, while the type-checker version is more
eager. Stage in the stricter check as a warning and we'll clamp down
on things later.
Generic methods declared in protocols (and extensions thereof) cannot
be used on existential values, because there is no way to specialize
them for all potential types. Diagnose such cases in Embedded Swift
mode and via `-Wwarning EmbeddedRestrictions`.
This adds a bunch more warnings to the standard library that we'll
need to clean up, probably by `#if`'ing more code out.
Part of rdar://119383905.
Move the diagnostic about non-final generic methods in classes up to
the type checker, so that it is available to `-Wwarning
EmbeddedRestrictions` and earlier in the pipeline. The SIL version of
this is still available as a backstop.
Yet another part of rdar://133874555.
Embedded Swift must defer some of the diagnostics about its
restrictions to late in the optimization pipeline, because some
source-level constructs (such as metatypes) are allowed in specific
cases that cannot be diagnosed in the type checker.
Put these diagnostics into the same EmbeddedRestrictions diagnostic
group as the type checker diagnostics, because that's the central
point at which we can direct folks to more information about the
restrictions in Embedded Swift.
Addresses rdar://119383905.
This attribute forces programmers to acknowledge every
copy that is required to happen in the body of the
function. Only those copies that make sense according
to Swift's ownership rules should be "required".
The way this is implemented as of now is to flag each
non-explicit copy in a function, coming from SILGen, as
an error through PerformanceDiagnostics.
The imported top-level module inherits the imports of all its
(transitive) submodules. Since multiple submodules can import the same
modules these need to be deduplicated to avoid redundant work.
swift_coroFrameAlloc was introduced in the Swift 6.2 runtime. Give it
the appropriate availability in IRGen, so that it gets weak
availability when needed (per the deployment target). Then, only
create the stub function for calling into swift_coroFrameAlloc or
malloc (when the former isn't available) when we're back-deploying to
a runtime prior to Swift 6.2. This is a small code size/performance
win when allocating coroutine frames on Swift 6.2-or-newer platforms.
This has a side effect of fixing a bug in Embedded Swift, where the
swift_coroFrameAlloc was getting unconditionally set to have weak
external linkage despite behind defined in the same LLVM module
(because it comes from the standard library).
Fixes rdar://149695139 / issue #80947.
When a module has been imported `@preconcurrency` in source, when it is printed
in a `swiftinterface` file it should be printed along with the attribute to
ensure that type checking of the module's public declarations behaves
consistently.
This fix is a little unsatisfying because it adds another a linear scan over
all imports in the source for each printed import. This should be improved, but
it can be done later.
Resolves rdar://136857313.
