Skip to content

[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
merged 23 commits into from
Apr 22, 2022

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Apr 22, 2022

This should not require swift changes. But 89b80bf in this PR is required by swiftlang/swift#42583

hamishknight and others added 22 commits April 14, 2022 21:50
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
@rintaro
Copy link
Member Author

rintaro commented Apr 22, 2022

@swift-ci Please test

@rxwei
Copy link
Contributor

rxwei commented Apr 22, 2022

@swift-ci please test

@rintaro
Copy link
Member Author

rintaro commented Apr 22, 2022

@rintaro rintaro merged commit bb35181 into swiftlang:swift/main Apr 22, 2022
@rxwei rxwei mentioned this pull request Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants