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.
When a non-Escapable value depends on the address of a trivial value, we use a
special computeAddressableRange analysis to compute the trivial value's
scope. Extend that analysis to include unreachable paths.
Fixes this pattern:
inlineStorage.span.withUnsafeBytes
where inlineStorage is a trivial type defined in the user module. This
does not reproduce directly with InlineArray, but it is a problem for
user modules that have their own trivial wrapper around an InlineArray.
Fixes rdar://161630684 (Incorrect diagnostic: lifetime-dependent value escapes its scope)
(cherry picked from commit 98b7d5906cffa0cf7a481ba47a6acd746e388ac9)
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)
We used to try to use `process_vm_readv()` if `CAP_SYS_PTRACE` is
enabled. This avoided using signal handlers to catch crashes when
we try to read through an invalid pointer, but it complicates the
code and it turns out not to work on some Linux kernels where
the `process_vm_readv()` syscall is unavailable.
rdar://159930644
`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)
