Skip to content

Conversation

@milseman
Copy link
Member

@milseman milseman commented Dec 19, 2024

Cherry-pick main improvements onto 6.1 release branch.

rdar://139574024
rdar://137602299
rdar://137607522
rdar://137810309
rdar://139573994

parispittman and others added 21 commits December 19, 2024 10:30
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 <natecook@apple.com>
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.
@milseman
Copy link
Member Author

@swift-ci please test

Copy link
Member

@natecook1000 natecook1000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🚀

@natecook1000
Copy link
Member

@swift-ci Please test

* Work around change in integer literal inference Related to swiftlang/swift#78371, but doesn't need to be reverted after that issue is fixed. * Fix availability for capture tests
@natecook1000
Copy link
Member

@swift-ci Please test Windows platform

@azharudd
Copy link

azharudd commented Jan 8, 2025

@swift-ci please test

@natecook1000 natecook1000 merged commit 03db4e2 into swiftlang:swift/release/6.1 Jan 8, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

7 participants