-
Notifications
You must be signed in to change notification settings - Fork 50
[Integration] main (06f40f6) -> swift/main #328
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
Merged
rintaro
merged 23 commits into
swiftlang:swift/main
from
rintaro:integration-main-06f40f6
Apr 22, 2022
Merged
[Integration] main (06f40f6) -> swift/main #328
rintaro
merged 23 commits into
swiftlang:swift/main
from
rintaro:integration-main-06f40f6
Apr 22, 2022
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
Previously we would form an `.other` character property kind for any unclassified properties, which crash at runtime as unsupported. Instead, switch to erroring on them. Eventually it would be nice if we could version this based on what the runtime being targeted supports.
Add backslash to the list of characters we don't consider valid for a character property name. This means that we'll bail when attempting to lex a POSIX character property and instead lex a custom character class. This allows e.g `[:\Q :] \E]` to be lexed as a custom character class. For `\p{...}` this just means we'll emit a truncated invalid property error, which is arguably more inline with what the user was expecting.. I noticed when digging through the ICU source code that it will bail out of parsing a POSIX character property if it encounters one of its known escape sequences (e.g `\a`, `\e`, `\f`, ...). Interestingly this doesn't cover character property escapes e.g `\d`, but it's not clear that is intentional. Given backslash is not a valid character property character anyway, it seems reasonable to broaden this behavior to bail on any backslash.
Clarify that `[:...:]` may be used outside of a custom character class, and discuss the character class disambiguation behavior.
This makes the changes necessary for _RegexParser to be imported as an implementation-only dependency. The change provides _StringProcessing wrappers for all `AST` types that need to be publicly visible via SPI, and a DSLTree.Node wrapper for internal conformance to _TreeNode. Co-authored-by: Richard Wei <[email protected]>
* Expose `matches`, `ranges` and `split` Publicize these API per the String Processing Algorithms proposal. The proposed ones return generic `Collection`, empowered by SE-0346. For now we'll wrap the results with a concrete `Array` until the language feature is ready. Co-authored-by: Michael Ilseman <[email protected]>
Move the closure argument in `replace` and `replacing` to the end of the argument list for trailing closure syntax. Add a test for replacing within a range.
This provides a RegexBuilder API that represents the same as `\O` in regex syntax.
This also moves QuantificationBehavior from the RegexBuilder module down to _StringProcessing, and renames it to RegexRepetitionBehavior.
Add the functions to string processing algorithms proposal and implement the change. Move the functions from `String` and `SubString` extensions to `BidirectionalCollection`. Add tests for `firstMatch`, `wholeMatch`, and `prefixMatch` that use a custom `BidirectionalCollection` type.
* Bring run time proposal up to speed * Update repo doc to be in line with SE
* Rename custom match prefix protocol and add doc comments * Update algo proposal prose
Moving `libswiftLexRegexLiteral()` and `libswiftParseRegexLiteral()` to the compiler repository because these functions are basically just briding the compiler to the actual lexing/parsing function. * Make some Lexing error APIs public. * Make LocatedErrorProtocol public and expose the `location` property * Shift the location of `LocatedError` in `parseWithDelimiters` so the client can get the valid string indices of the passed-in literal string.
Preparation for location aware diagnostics in the compiler
@swift-ci Please test |
@swift-ci please test |
rxwei
approved these changes
Apr 22, 2022
Closed
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.
This should not require swift changes. But 89b80bf in this PR is required by swiftlang/swift#42583