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.
Untyped throws depends on existentials (`any Error`), and is therefore
not available in Embedded Swift. Introduce a diagnostic that diagnoses
any use of untyped throws, suggesting that one use typed throws
instead.
Make this an opt-in diagnostic enabled with `-Wwarning
EmbeddedRestrictions`, whether in Embedded Swift or not, using the
"default ignore" flag on these new warnings. Document this new
diagnostic group, and put the existing Embedded Swift error about
weak/unowned references in it as well.
Part of the general push to have the type checker identify code that
will not compile as Embedded Swift earlier, rdar://133874555.
We still need to solve a branch with a ReturnStmt to avoid leaving
the contextual result type unbound. This isn't currently legal anyway,
so isn't likely to come up often in practice, but make sure we can
still solve.
