* AttributedString index validity APIs
* Move canImport(Synchronization) into function body
* Remove unnecessary bounds checks from validity expression
* Update FOUNDATION_FRAMEWORK code to provide Index versions
* Implement unlocalized range(of:) for AttributedString
`String` has a natively-implemented `_range(of:options:)`. This PR implements `AttributedString`'s `range(of:options:)` with that when localization support is not needed.
Ideally we should implement this on `BigString` to avoid iterating through `Characters`, which is tracked as a future TODO.
This function takes a `Locale` argument, which isn't available in FoundationEssentials. We could move this to FoundationInternalization where `Locale` is defined, but some clients use it with `locale: nil` and do not need localized results. To make the best of this let's add a non-localized version for FoundationEssentials.
* Enable AttributedString.range(of:) when locale is nil
* rdar://108152217 Start using Rope for attribute run storage
- Replace `Array<_InternalRun>` with `Rope<_InternalRun>`.
- Fix semantics of AttributeRunBoundaries.character. It no longer pretends that attributes can be tied to grapheme clusters — that never actually worked properly, and it cannot be supported without breaking the intended use case.
- Remove cache of latest run position; log(n) might be fast enough that we don’t need to worry about that.
- Switch AttributedString.Guts members to take/return BigString.Index values, not AttributedString indices. This cuts down on constant back-and-forth conversions.
- Discard unused Guts members; update remaining mutation methods to follow Swift naming conventions.
- Stop using the `public extension` language misfeature.
* rdar://108152217 Apply notes from code review
AttributedString.CharacterView and AttributedString.UnicodeScalarView
did not use the right semantics in the case when the underlying text
was not touched. It’s okay in that case to not mutate text storage,
but we still want to override the attributes within the subrange as if
the client actually did replace text — as in, we want to use precisely
the same attribute storage for the range on both paths.
Also, make sure we correctly enforce attribute constraints in the
`!hasStringChanges` case, in both views.
* rdar://108152217 Fix logic error in AttributedString.Runs.subscript
(Discovered during code review.)
* rdar://108152217 Clean up CharacterView/UnicodeScalarView mutations & update failing test
* rdar://108152217 Apply review notes
* rdar://105027055: Do not use as-casts in specializations.
Introduce _specializingCast and use it instead of `as?`-casts inside
if ladders that implement generic specialization.
`as?` invokes undesirable runtime machinery such as bridging checks.
* rdar://105027055: Ensure AttributedString views have properly aligned bounds
* rdar://105027055: Implement index(_:offsetBy:limitedBy:) in AttributedString views
* rdar://107778676 Stop vendoring the Collections package
* rdar://107778676 Fix test expectation
AttributedString.CharacterView needs to round all indices down to the
nearest Character boundary to avoid semantic issues with its
Collection conformance. This means that CharacterView slices can never
start or end in between Character boundaries.
* Remove a stray print statement
