-
Notifications
You must be signed in to change notification settings - Fork 50
[Integration] main -> swift/main #192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
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
This is a first approximation of a CMake based build for this repository. The intent here is to localize the build rules for the repository to allow it to be consumed during the build of the toolchain. This allows the source list to be maintained in the repository as the source of truth rather than be explicitly listed in the swift repository. For general purpose development, the SPM based build is recommended. Unless there is a specific need for the tests to be included, testing should be done via the SPM build. This change is sufficient to build the content though does not perform the install or export steps which will be required to consume the results in the Swift build. Example invocation: ~~~ cmake -B S:\b\16 ^ -D CMAKE_BUILD_TYPE=Release ^ -D ArgumentParser_DIR=S:\b\10\cmake\modules ^ -G Ninja ^ -S S:\SourceCache\swift-experimental-string-processing cmake --build S:\b\16 ~~~
Previously we followed PCRE's parsing of this syntax such that it may either be an octal sequence or backreference depending on a list of heuristics. However this model is complicated and not particularly intuitive, especially as there are other engines that disambiguate using subtly different rules. Instead, always parse `\DDD` as a backreference, unless it begins with `0`, in which case it is an octal sequence. This matches ICU and Java's behavior. Once we start validating group references, we can then start emitting an error on invalid backreferences using this syntax, and suggest prefixing with 0 if an octal sequence is desired.
Lots of ME stuff was annotated with vestigial public
build: add a CMake based build
@shahmishal Could you let us know when the CI has been configured to run build-script tests on the swift/main branch? |
rxwei
added a commit
to rxwei/swift
that referenced
this pull request
Feb 28, 2022
Switch to using swift/main as the integration branch for apple/swift-experimental-string-processing. Integration process documentation: swiftlang/swift-experimental-string-processing#170 Friend PR: swiftlang/swift-experimental-string-processing#192
This was referenced Feb 28, 2022
To avoid confusion with more general regex lexical analysis.
Introduce a DelimiterLexer type to perform the lexing.
This matches the behavior of the C++ lexer for string literals.
Allow the C++ lexer to form a tok::regex_literal. This avoids generic fallback behavior, and better allows for things like code completion. The test case for this will be in the C++ repo.
If a single quote is encountered with a prefix of either `(?`, `(?(`, `\k`, `\g` or `(?C`, continue to scan ahead to a closing `'`. Such prefixes would not be valid endings for a regex literal anyway, and this lets us handle the single quote variant of their syntax. For the group name cases, further refine this skipping behavior by only skipping over characters that could possibly appear in that case. This improves diagnostic behavior by ensuring we don't go wandering off into Swift code.
Change the default script property behavior for an unqualified value e.g `\p{Greek}` from `\p{Script=Greek}` to `\p{Script_Extension=Greek}`. This is arguably the more intuitive behavior, and matches what Perl does.
Adds a test with a `SemanticVersion` type that conforms to `CustomRegexComponent`.
Document specially integrated modules and integration process.
This enables the `\y` and `\Y` anchors in regex literals and `Anchor.textSegmentBoundary` in the DSL. Note: This also includes `UnicodeScalar` conformance to `RegexProtocol`, which acts like Unicode scalar literals in regex literals.
@shahmishal I'm closing this PR since the current |
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.
No description provided.