Explanation: Unowned result conventions do not work well with OSSA. Retain the
result right after the call when we come out of OSSA so we can treat the
returned value as if it was owned when we do optimizations.
This fix a miscompilation due to the DestroyAddrHoisting pass hoisting destroys
above copies with unowned sources. When the destroyed object was the last
reference to the pointed memory the copy is happening too late resulting in
a use after free.
Issues: rdar://160462854
Original PRs: #84612
Risk: We change where retaining of the unowned return values
happen in the optimization pipeline. It is hard to anticipate all the
possible effects but it should make the optimizer more correct.
Testing: Added a compiler test.
Reviewers: @eeckstein, @atrick
Follow up to https://github.com/swiftlang/swift/pull/84635/.
The metadata accessor for a variadic generic type takes as arguments
packs of metadata records and witness tables, and each such pack is
passed in a buffer. So the call to any such accessor is not correctly
annotated memory(none).
rdar://161606892
The metadata accessor for a variadic generic type takes as arguments
packs of metadata records and witness tables, and each such pack is
passed in a buffer. So any such accessor is not correctly annotated
`memory(none)`.
rdar://161606892
- Calls to variadic-generic protocol requirements weren't applying
substitutions properly, so expansion-sensitive types in the callee
signature weren't pairing properly with their expansions in the
caller.
- emitPackTransform had an over-destroy if the transformation function
actually emitted into the temporary element directly.
- There were some MV ownership assertions that were wrong, which
revealed that the corresponding code really didn't handle consuming/
borrowing mismatches properly at all.
- We were completely mishandled consuming packs.
Fixes#81002, #80995, and #81600.
Always give up early when attempting to deserialize a protocol
conformance broken by a context change. Don't attempt to replace missing
members of the conformance signature with invalid one, just mark the
whole protocol conformance as invalid.
The previous recovery logic, only for SourceKit mode and LLDB, was
inserting invalid conformances in the signature instead of dropping the
whole protocol conformance. It lead to failures later in the same
`finishNormalConformance` when accessing the invalid conformances.
rdar://98925842
Ttheir availability is going to match the property itself.
This is a workaround for lazy type-checking because synthesis
of accessors for such properties requires a reference to
`self` which won't be available because pattern binding
for the variable was skipped.
Resolves: rdar://129359362
Resolves: rdar://159463230
Resolves: https://github.com/swiftlang/swift/issues/84041
(cherry picked from commit 6e7de5c1e0)
`nonisolated(nonsending)` is not presented in interface types
which means that references to declarations that have this attribute
require a function conversion to apply it. Function conversion
checking should detect that and avoid sendability checking for
situations like that but there is really no conversion there.
(cherry picked from commit ce3310050b)
The isolation doesn't change in this cause and making function type
non-Sendable means that it woun't be able to leave the current concurrency
domain and the compiler won't generate a thunk.
(cherry picked from commit 40c9674dfd)
Explicit closure expressions gets their isolation inferred during
actor isolation checking, if they appear as a sub-expression to
a function conversion we need to delay function checking until
the closure was processed. It shouldn't matter for other cases.
(cherry picked from commit 61fbaa7af7)
If there are no explicit concurrency attributes, isolated parameters,
or captures associated with the closure it should infer `nonisolated(nonsending)`
for the parent conversion injected by the solver (this conversion is injected
because the solver cannot check captures to elide it).
The change pushes `isIsolationInferenceBoundaryClosure` check down
with added benefit of getting preconcurrency context from the parent.
(cherry picked from commit 3ae34e8e68)
As a follow-up fix for https://github.com/swiftlang/swift/pull/83545, avoid
incorrectly diagnosing isolated deinit availability during module emission
jobs, which skip type checking non-inlinable function bodies and therefore
don't build accurate availability scopes for those bodies. It's ok to skip
these diagnostics during module emission since they should still be emitted
during compilation jobs.
Resolves rdar://161178785.
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
(cherry picked from commit e78ce6165f)
Explanation: Large trivial types were copied via memcpy instead of doing a
field-wise copy. This is incorrect for types with reference fields where we also
need to bump the corresponding refcounts. This PR makes sure that trival
C++ types with reference members are not trivial in Swift.
Issues: rdar://160315343
Original PRs: #84321
Risk: There is a low chance of breaking source compatibility as some
types that used to be BitwiseCopyable are no longer considered as such.
However, code relying on that probably has latent memory safety bugs.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @j-hui
https://github.com/swiftlang/swift/pull/82616 added a new exposure kind
for the `@_expose` attribute, but did not update the serialization
format to account for the new kind. This caused a crash when
serializing a module that used `@_expose(wasm)`.
Allow referencing an `@_spi_available` decl in extensions to
`@_spi_available` types. This is a narrow fix as it should really be
handled as part of the context check but that check is currently too
permissive.
Fow now let's narrowly allow legal code. And then we should look at
revisiting the SPI availability logic, separate it from normal SPI and
treat more like availability.
Adding a test comparing the behavior of `@_spi` with `@_spi_available`
to document the current implementation.
rdar://159292698
WebAssembly does not have a reserved address space by default, so we
need to explicitly reserve low addresses for extra inhabitants for
enum types with pointer payloads. https://github.com/swiftlang/swift/pull/39300
added `--global-base` to reserve low data addresses, but we also need
to reserve low function addresses with `--table-base` for function
pointers because WebAssembly uses a separate address space for function
pointers.
This is a new case that comes up with `InlineArray`, since an `InlineArray`
with unknown count but known trivial element type is trivial but still
address-only due to its unknown size. We are inconsistent about whether
we emit formal copies or not of these values; they should generally
be unnecessary as long as the memory location of a value is sufficiently
long-lived, but the SIL verifier still reasonably considers a `[take]` as
an invalidation of the memory, even though at runtime a take is a no-op.
Since the take is unnecessary, we can just not take when we copy out of
a trivial address location. Fixes#84141 | rdar://160007939.
closures.
The fixes for initializers are just setting the stage for doing this
properly: we should be able to just change the isolation computation
in Sema and fix up the tests.
The first bug is that we weren't computing isolation correctly for
nested defers. This is an unlikely pattern of code, but it's good to fix.
The second bug is that getActorIsolationOfContext was looking through
defers, but getActorIsolation itself was not. This was causing defer
bodies to be emitted in SILGen without an isolation parameter, which
meant that #isolation could not possibly provide the right value. Fixing
this involves teaching SILGen that non-async functions can have
nonisolated(nonsending) isolation, but that's relatively straightforward.
This commit doesn't fix #isolation or adequately test SILGen, but that'll
be handled in a follow-up.
