Update swift 6.1 #795
Open
Update swift 6.1 #795
Conversation
This file contains 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
We are going to use a different contributing template go forward after migration
after this repo migrates to /swiftlang today, it will be opt-ing in to the org wide code of conduct that is present at the root .github config folder. Having this file present means that it is opt-ing out of the org wide and has its own process which will not be true.
As of the Swift 6 compiler, `@_implementationOnly import` is deprecated in favor of `internal import` and as a result the use of `@_implementationOnly import` in this project is generating a lot of diagnostic noise when building the Swift standard library. For Swift libraries with library evolution, `@_implementationOnly import` and `internal import` are roughly functionally equivalent, aside from improved diagnostics for `internal import`. For non-resilient libraries, the main difference is that `internal import` does not actually hide a module dependency from downstream clients because the layout of a type in a non-resilient library may depend on types coming from an `internal import` (with `@_implementationOnly import` the same situation would result in a silent mis-compile, which is the reason that `@_implementationOnly import` is deprecated). The `_RegexParser` module dependency does not need to be hidden from clients since it is installed in standard locations in the SDK/toolchain. Therefore this migration should be safe, regardless of library resilience mode.
The new module and overlay were merged into Swift 6 in swiftlang/swift#74758.
Cleanup algorithms code Delete lots of dead code, get off of collections and onto iterators, simplify implementations. --------- Co-authored-by: Nate Cook <[email protected]>
Refactor executor interfaces as well
Make processor reset faster by tracking dirty registers and only clearing Arrays that are non-empty.
The RegexBuilder tests for working with composed regexes with capture tuple types that don't play well with DSL methods were inadvertently disabled in a previous commit (by me). This re-enables those tests.
Rather than have the whole-match capture be a stored capture, we handle it specially. This speeds up processor resets as we do not need to reset a stored capture (especially when the regex has no other captures). It also speeds up the creation of save points and backtracking, as it's one less capture to save/restore.
Moves register initialization to the program where it can be done once. Speeds up use cases where the same regex is applied to many small inputs.
|
@swift-ci please test |
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.
Cherry-pick main improvements onto 6.1 release branch.
rdar://139574024
rdar://137602299
rdar://137607522
rdar://137810309
rdar://139573994