- **Explanation**: Fixes a crash with key paths on 32-bit platforms reproducible for types that have 16-byte alignment.
The intended bit layout of `ComputedArgumentSize` in `KeyPath` on 32-bit is:
```
┌───────┬───────────┐
│ bits │ field │
├───────┼───────────┤
│ 0–27 │ size │
├───────┼───────────┤
│ 28–29 │ padding │
├───────┼───────────┤
│ 30–31 │ alignment │
└───────┴───────────┘
```
Currently, `alignmentMask = 0x6000_0000`, i.e. bits 29–30, not 30–31. It overlaps paddingMask (bits 28–29) at bit 29, meaning that alignment and padding unintentionally share a bit. With `alignmentShift = 30`, storing `shift = 2 << 30` places 1 at bit 31, which the mask doesn't cover.
Correct value is `0xC000_0000` covers bits 30–31, which matches `alignmentShift = 30` so both `shift = 1` and `shift = 2` round-trip, and it does not overlap with `paddingMask = 0x3000_0000` (bits 28–29). It also mirrors the 64-bit layout (top bits of the word reserved for alignment, just 2 of them instead of 1).
- **Scope**: Limited to 32-bit platforms.
- **Issues**: rdar://175799967
- **Risk**: Low due to increased test coverage.
- **Testing**: Previously crashing on 32-bit platforms sample code is now added to the test suite.
Functions like withUnsafeBufferPointer are, by themselves, safe to
call. It's only the operations on the unsafe pointers passed into the
closure that are the safety issue.
This was the intent spelled out in SE-0458 but was not fully realized
in the library.
Fixes rdar://174519372.
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
This applies more annotations in the `INTERNAL_CHECKS_ENABLED` disabled
paths, Windows, 32-bit, and non-ObjC paths. Interestingly enough, there
are a couple of compiler intrinsics which are also uncovered.
PR 79186 (https://github.com/swiftlang/swift/pull/79186) moved one of
the mandatory passes from the C++ implementation to the Swift
implementation resulting in a compiler that is unable to build the
standard library. The pass used to ensure that inaccessible control-flow
positions after an infinite loop was marked with `unreachable` in SIL.
Since the pass is no longer running, any function that returns a value
that also has an infinite loop internally must place a fatalError after
the infinite loop or it will fail to compile as the compiler will
determine that the function does not return from all control flow paths
even though some of the paths are unreachable.
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
Enable KeyPath/AnyKeyPath/PartialKeyPath/WritableKeyPath in Embedded Swift, but
for compile-time use only:
- Add keypath optimizations into the mandatory optimizations pipeline
- Allow keypath optimizations to look through begin_borrow, to make them work
even in OSSA.
- If a use of a KeyPath doesn't optimize away, diagnose in PerformanceDiagnostics
- Make UnsafePointer.pointer(to:) transparent to allow the keypath optimization
to happen in the callers of UnsafePointer.pointer(to:).
Max Desiatov
indextrown
Doug Gregor
Alejandro Alonso
Gabor Horvath
Stephen Canon
Allan Shortlidge
Saleem Abdulrasool
Evan Wilde
Guillaume Lessard
Amritpan Kaur
nate-chandler
Kuba Mracek
Nate Chandler
Joe Groff
Guillaume Lessard