This changes the implementation for `Collection.difference(from:)` to
use a linear-space complexity variation of the same Myers algorithm. The
new version is similar in execution time to the existing one, but should
alleviate memory pressure when diffing collections where the number of
differences approaches the size of the collection. While the new
algorithm returns a set of changes that is the same size as the previous
version, the specific changes are not guaranteed to be the same.
rdar://155829876
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.
Where we have rethrowing versions of functions that have typed-throws
counterparts that are only retained for ABI compatibility, wrap them
in `#if !$Embedded` so they aren't compiled into the Embedded version
of the standard library. This eliminates warnings about this code,
which cannot actually be used with arbitrary errors anyway.
It isn't clear why @_unsafeNonescapableResult was applied to
Mutable[Raw]Span.init(). It was either a mistake or temporary workaround for
some compiler bug.
Currently we create an absolute one -- this prevents to use the partial
toolchain before the installation phase (namely for configurations that
run Swift tests on a different device than the builder).
Addresses rdar://160277259
`swift_coroFrameAlloc` is needed by `_read`/`_modify` accessors
`swift_deallocUninitializedObject` which I believe is needed for failable class initializers
Resolves rdar://157028375
Resolves rdar://157276375
The interior wrapping in Result<T, U> is a little unfortunate, but is
currently necessary because we end up with extra stack allocations
along the error-handling path in a do..catch that aren't there when
using untyped throws. We can simplify the implementation if we can
eliminate the extraneous stack allocation.
Fixes rdar://134973620.
The body seems to only reinterpret pointer types (`withMemoryRebound`).
Inlining it should not lead to code size gains and has shown to reduce code size.
Carefully overhaul our word breaking implementation to follow the recommendations of Unicode Annex #29. Start exposing the core primitives (as well as `String`-level interfaces), so that folks can prototype proper API for these concepts.
- Fix `_wordIndex(after:)` to always advance forward. It now requires its input index to be on a word boundary. Remove the `@_spi` attribute, exposing it as a (hidden, but) public entry point.
- The old SPIs `_wordIndex(before:)` and `_nearestWordIndex(atOrBelow:)` were irredemably broken; follow the Unicode recommendation for implementing random-access text segmentation and replace them both with a new public `_wordIndex(somewhereAtOrBefore:)` entry pont.
- Expose handcrafted low-level state machines for detecting word boundaries (_WordRecognizer`, `_RandomAccessWordRecognizer`), following the design of `_CharacterRecognizer`.
- Add tests to reliably validate that the two state machine flavors always produce consistent results.
rdar://155482680
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
Amend formatting of `Substring.utf8Span` example code.
Use DocC tables in `Unicode.UTF8.ValidationError` overview.
---------
Co-authored-by: Alex Martini <amartini@apple.com>
Fixes a build problem when using a mainline compiler with a 6.2 Swift.swiftinterface file.
This was caused by mistakenly cherry-picking the `#if $AddressOfProperty` conditions in the stdlib into 6.2 without the required compiler change.
It seems that the restriction preventing these from working was
lifted.
The behavioral difference is that in Swift 5 mode, we don't
actually open AnyObject like this, so the old operator could
not be used with class-bound existentials.
I added a trivial test case just to ensure that calls to ===
type check correctly in both language modes.
Fixes rdar://156095800.
