[pull] swiftwasm from main #4449
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…sequences of SE-0180
… indices Assign some previously reserved bits in String.Index and _StringObject to keep track of their associated storage encoding (either UTF-8 or UTF-16). None of these bits will be reliably set in processes that load binaries compiled with older stdlib releases, but when they do end up getting set, we can use them opportunistically to more reliably detect cases where an index is applied on a string with a mismatching encoding. As more and more code gets recompiled with 5.7+, the stdlib will gradually become able to detect such issues with complete accuracy. Code that misuses indices this way was always considered broken; however, String wasn’t able to reliably detect these runtime errors before. Therefore, I expect there is a large amount of broken code out there that keeps using bridged Cocoa String indices (UTF-16) after a mutation turns them into native UTF-8 strings. Therefore, instead of trapping, this commit silently corrects the issue, transcoding the offsets into the correct encoding. It would probably be a good idea to also emit a runtime warning in addition to recovering from the error. This would generate some noise that would gently nudge folks to fix their code. rdar://89369680
…f indices This removes an unnecessary opaque call from the inlinable path, but it preserves a runtime version check.
… of common routines There are three flavors, corresponding to i < endIndex, i <= endIndex, and range containment checks. Additionally, we have separate variants for index validation in substrings.
This used to forward to `Slice.replaceSubrange`, but that’s a generic algorithm that isn’t aware of the pecularities of Unicode extended grapheme clusters, and it can be mislead by unusual cases, like a substring or subrange whose bounds aren’t `Character`-aligned, or a replacement string that starts with a continuation scalar.
…gorithms To prevent unaligned indices from breaking well-defined index distance and index offset calculations, round every index down to the nearest whole Character. For the horrific details, see the forum discussion below. https://forums.swift.org/t/string-index-unification-vs-bidirectionalcollection-requirements/55946 To avoid rounding from regressing String performance in the regular case (when indices aren’t being passed across string views), introduce a new String.Index flag bit that indicates that the index is already Character aligned.
…g string Prefer direct stored properties to computed ones — there is no reason to risk inlining issues, esp. since things like `Slice.base` aren’t even force-inlined. Prefer using `_wholeGuts` to spelling out the full incantation.
…e internal types @inlinable (This really ought to be diagnosed by the compiler.)
- Validate that the index has the same encoding as the string - Validate that the index is within bounds
…ding down to Character
…riginal index Whether the limit actually applies depends on how it’s ordered relative to the original index `i`, not the one we round down to the nearest Character.
`index(after:)`/`index(before:)` aren’t inlinable, so I don’t expect force-inlining the subscript has much benefit.
This will eliminate unnecessary CoW copies when calling mutating Unicode scalar view methods directly through this property.
Also, in UTF-8 slices, forward collection methods to the base view instead of `Slice`, to make behavior a bit easier to understand. (There is no need to force readers to page in `Slice` implementations _in addition to_ whatever the base view is doing.)
Also, in UTF-16 slices, forward collection methods to the base view instead of `Slice`, to make behavior a bit easier to understand. (There is no need to force readers to page in `Slice` implementations _in addition to_ whatever the base view is doing.)
These weren’t doing the right thing, and all callers have now migrated to the new `_StringGuts.validate*` methods, which combine bounds checks with encoding validation and scalar alignment.
…e-relations-solver-based [CodeCompletion] Report type relations when completing inside result builders
Concurrency: include missing header
These were accidentally left off - turn them on subject to the -enable-parameterized-existential-types flag.
[Test] Fix broken IDE test
This was added recently but not initialized in symbolgraph-extract. We never output Clang imported symbols from this tool, so always passing false is fine for now.
Test-case should no longer produce "type of expression is ambiguous" fallback diagnostic. Resolves: rdar://66110075
…on even when the compiler does not support the C++17 over-aligned new feature (and avoid using new anyway since it might be overridden by something else in the process.)
[stdlib] Fix String indexing edge cases, anomalies & validation bugs
Apply a blanket pass of including `new` for the placement new allocation and namespacing the call to the global placement new allocator. This should repair the Android ARMv7 builds.
…swift-interface ModuleInterface: Wrap synthesized extensions in swiftinterfaces with feature guards
existential metatype. Until we model ExistentialMetatypeType as ExistentialType(MetatypeType), type resolution needs to look through the instance type repr when resolving a metatype. Otherwise, there's no way to distinguish between P.Type.Type, which is an existential metatype, and (any P.Type).Type, which is the static metatype of an existential metatype.
[SymbolGraph] Initialize newly added IncludeClangDocs field
[TypeChecker] NFC: Un-XFAIL SwiftUI test-case which has been fixed
Turn on Existential Metatypes for Parameterized Existential Types
runtime: blanket application of namespacing and inclusion of `new`
…ue-aligned-allocation
[NFC] Remove Legacy Parser-Based Redeclaration Diagnostics
…ence-swiftinterface
…f variable For all of the `build*` calls, let's use a special variable declaration `$builderSelf` which refers to a type of the builder used. This allows us to remove hacks related to use of `TypeExpr`. Reference to `$builderSelf` is replaced with `TypeExpr` during solution application when the builder type is completely resolved.
This fixes a Windows regression triggered by swiftlang#41417.
…bjc-optional-component CS: `optional` storage key path components are read-only
[BuilderTransform] Replace use of `TypeExpr` with a special $builderSelf variable
…atype-resolution [Type Resolution] Resolve `(any P.Type).Type` as the metatype of an existential metatype.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )