There's a longstanding problem in implementing `-isEqualToString:`,
where if you don't know how to get fast access to the other NSString's
contents, you have to pick between doing it character by character (very
slow), or calling [other isEqualToString: self], which risks infinite
recursion if the other string does the same.
This cuts the gordian knot by adding a new method
`isEqualToBytes:encoding:count:`, so you can get the contents out of
`self`, and hand it to the other string, confident that it will not need
to (nor, in fact be able to) ask you anything that might recurse.
<!--
The main branch is now in convergence, which means major changes, such
as large refactoring or new features, should be avoided. This strategy
is intended to maintain the stability of the Swift 6.4 release leading
up to the May 4th branch. For any work that requires broad changes or
introduces new features, create a feature branch and open a draft pull
request. All updates to the swiftlang/swift repository’s main branch
require approval from the release managers. A pull request targeting
swiftlang/swift will automatically add release managers. You can also
contact them via @release-managers in the forum group.
-->
<!-- Please fill out the following form: -->
- **Explanation**: This reverts commit
5ece334724 which aimed to generalize
Sequence methods for typed throws and resolve its side effects on
overload resolution when a type conforms to both Sequence and
AsyncSequence. There appears to be, at least, one more unanticipated
side-effect, hence this pre-emptive revert in view of the soon-to-be
Swift 6.4 release branching.
<!--
A description of the changes. This can be brief, but it should be clear.
-->
- **Scope**: The said commit is reverted, preserving the recent
~Copyable/consuming alterations to Sequence.reduce(\_:\_:) (#85716).
<!--
An assessment of the impact and importance of the changes. For example,
can
the changes break existing code?
-->
- **Issues**: Under investigation
<!--
References to issues the changes resolve, if any.
-->
- **Risk**: Low
<!--
The (specific) risk to the release for taking the changes.
-->
- **Testing**: None
<!--
The specific testing that has been done or needs to be done to further
validate any impact of the changes.
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
- **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.
The existing code (new in 6.4) has a special case for when the exponent
was zero to do a straight conversion instead of splitting the integer
and doing an FMA. However, this either gave incorrect results or trapped
when signed `digits` was too large to fit into an `Int64`. The old
approach could be made to work without too much fuss, but we can also
just let this case fall through and use the non-zero exponent path,
which simplifies the code somewhat. We might want to rework all of this
in the future for further performance gains, but this simplifying fix is
totally straightforward and easy to take for now.
Resolves rdar://175568950
<!-- Please fill out the following form: -->
- **Explanation**:
Eliminates a special case for String->Double conversion that introduced
a bug for certain values, allowing execution to fall through into more
general code that handles the special case correctly as well.
- **Scope**:
Narrowly-focused. Allows us to get the correct result for some inputs
that would otherwise regress in 6.4 and produce values of the wrong
sign.
- **Issues**:
rdar://175568950
- **Risk**:
Low
- **Testing**:
No special testing required; added new test cases to the stdlib tests to
exercise the paths in question.
Guillaume Lessard
Alejandro Alonso
David Smith
Doug Gregor
Ben Cohen
Guillaume Lessard
Max Desiatov
Clinton Nkwocha
Stephen Canon