Repository files navigation

An early experimental general-purpose pattern matching engine for Swift.

SeeDeclarative String Processing Overview

• Swift Trunk Development Snapshot DEVELOPMENT-SNAPSHOT-2022-04-20 or later.

To try out the functionality provided here, download the latest open source development toolchain. Import_StringProcessing in your source file to get access to the API and specify-Xfrontend -enable-experimental-string-processing to get access to the literals.

For example, in aPackage.swift file's target declaration:

.target(    name:"foo",    dependencies:["depA"],    swiftSettings:[.unsafeFlags(["-Xfrontend","-enable-experimental-string-processing"])]),

_RegexParser and_StringProcessing are specially integrated modules that are built as part of apple/swift.

Specifically,_RegexParser contains the parser for regular expression literals and is built both as part of the compiler and as a core library._CUnicode and_StringProcessing are built together as a core library named_StringProcessing.

Themain branch is the branch for day-to-day development. Generally, you should create PRs against this branch.

Branches whose name starts withswift/ are Swift integration branches similar to those inapple/llvm-project. For each branch, dropping theswift/ prefix is the corresponding branch inapple/swift.

A pair of corresponding branches are expected to build successfully together and pass all tests.

To integrate the latest changes in apple/swift-experimental-string-processing to apple/swift, carefully follow the workflow:

• Create pull requests.
  • Create a branch from a commit onmain that you would like to integrate intoswift/main.
  • Create a pull request in apple/swift-experimental-string-processing from that branch toswift/main, e.g. "[Integration] main () -> swift/main".
  • If apple/swift needs to be modified to work with the latestmain in apple/swift-experimental-string-processing, create a pull request in apple/swift.Note: Since CI in apple/swift-experimental-string-processing has not yet been set up to run full toolchain tests, you should create a PR in apple/swift regardless; if the integartion does not require changing apple/swift, create a dummy PR in apple/swift by changing the README and just not merge it in the end.
• Trigger CI.
  • In the apple/swift-experimental-string-processing pull request, trigger CI using the following command (replacing<PR NUMBER> with the apple/swift pull request number, if any):

    apple/swift#<PR NUMBER> # use this line only if there is an corresponding apple/swift PR@swift-ci please test

  • In the apple/swift pull request (if any), trigger CI using the following command (replacing<PR NUMBER> with the apple/swift-experimental-string-processing pull request number):

    apple/swift-experimental-string-processing#<PR NUMBER>@swift-ci please test

• Merge when approved.
  • Merge the pull request in apple/swift-experimental-string-processing as amerge commit.
  • Merge the pull request in apple/swift (if any).

Compiler integration can be tricky. Use special caution when developing_RegexParser and_StringProcessing modules.

• Do not change the names of these modules without due approval from compiler and infrastructure teams.
• Do not modify the existing ABI (e.g. C API, serialization format) between the regular expression parser and the Swift compiler unless absolutely necessary.
• Always minimize the number of lockstep integrations, i.e. when apple/swift-experimental-string-processing and apple/swift have to change together. Whenever possible, introduce new API first, migrate Swift compiler onto it, and then deprecate old API. Use versioning if helpful.
• In_StringProcessing, do not write fully qualified references to symbols in_CUnicode, and always wrapimport _CUnicode in a#if canImport(_CUnicode). This is because_CUnicode is built as part of_StringProcessing with CMake.