-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Integrate experimental string processing modules and enable end-to-end regex. #40531
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,7 +6,16 @@ | |
# See http://swift.org/LICENSE.txt for license information | ||
# See http://swift.org/CONTRIBUTORS.txt for Swift project authors | ||
|
||
file(GLOB_RECURSE _LIBSWIFT_EXPERIMENTAL_REGEX_SOURCES | ||
"${EXPERIMENTAL_STRING_PROCESSING_SOURCE_DIR}/Sources/_MatchingEngine/*.swift") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Usually we don't collect sources with glob, but list all sources in the cmake files There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Because sources are from a separate repo that changes very rapidly, IMO listing sources would involve a lot of pull requests to apple/swift just to update the source list which then slows down development of the string processing repo. With glob, we can add files without submitting PRs the compiler repo unless we need to change the compiler interface. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Either is ok, as we want to be tag-based. The hazard of manually listing files is that these things easily fall out of sync and we can think we've added API only to find out we haven't. We're not talking about just compiler-visible sources but adding public stdlib API, so this is a hazard that is not otherwise checked by the build system. What's the hazard of globbing? I think this would be very interesting to know so that we're not cargo-culting an approach built for a completely different integration model. |
||
set(LIBSWIFT_EXPERIMENTAL_REGEX_SOURCES) | ||
foreach(source ${_LIBSWIFT_EXPERIMENTAL_REGEX_SOURCES}) | ||
file(TO_CMAKE_PATH "${source}" source) | ||
list(APPEND LIBSWIFT_EXPERIMENTAL_REGEX_SOURCES ${source}) | ||
endforeach() | ||
message(STATUS "Using Experimental String Processing library for libswift ExperimentalRegex (${EXPERIMENTAL_STRING_PROCESSING_SOURCE_DIR}).") | ||
|
||
add_libswift_module(ExperimentalRegex | ||
Regex.swift | ||
) | ||
"${LIBSWIFT_EXPERIMENTAL_REGEX_SOURCES}" | ||
Regex.swift) | ||
|
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1,10 @@ | ||
// RUN: %target-typecheck-verify-swift -enable-experimental-string-processing | ||
// REQUIRES: libswift | ||
|
||
var s = 'abc' | ||
_ = 'abc' | ||
|
||
var s1 = ('*', '+', '?') | ||
// expected-error@-1 3{{cannot start regex with quantifier}} | ||
_ = ('[*', '+]', '.]') | ||
// expected-error@-1 {{cannot parse regular expression}} | ||
|
||
var s2 = '\w+' | ||
var s3 = '\'\\' | ||
_ = '\w+' | ||
_ = '\'\\' |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
// RUN: %target-run-simple-swift(-Xfrontend -enable-experimental-string-processing) | ||
|
||
// REQUIRES: libswift,string_processing,executable_test | ||
|
||
import StdlibUnittest | ||
|
||
var RegexBasicTests = TestSuite("RegexBasic") | ||
|
||
extension String { | ||
func expectMatch<T>( | ||
_ regex: Regex<T>, | ||
file: String = #file, | ||
line: UInt = #line | ||
) -> RegexMatch<T> { | ||
guard let result = match(regex) else { | ||
expectUnreachable("Failed match", file: file, line: line) | ||
fatalError() | ||
} | ||
return result | ||
} | ||
} | ||
|
||
RegexBasicTests.test("Basic") { | ||
let input = "aabccd" | ||
|
||
let match1 = input.expectMatch('aabcc.') | ||
expectEqual("aabccd", input[match1.range]) | ||
expectEqual(.empty, match1.captures) | ||
|
||
let match2 = input.expectMatch('a*b.+.') | ||
expectEqual("aabccd", input[match2.range]) | ||
expectEqual(.empty, match2.captures) | ||
} | ||
|
||
RegexBasicTests.test("Captures") { | ||
let input = """ | ||
A6F0..A6F1 ; Extend # Mn [2] BAMUM COMBINING MARK KOQNDON..BAMUM \ | ||
COMBINING MARK TUKWENTIS | ||
""" | ||
let regex = '([0-9A-F]+)(?:\.\.([0-9A-F]+))?\s+;\s+(\w+).*' | ||
let match1 = input.expectMatch(regex) | ||
expectEqual(input[...], input[match1.range]) | ||
expectEqual( | ||
.tuple([ | ||
.substring("A6F0"), | ||
.optional(.substring("A6F1")), | ||
.substring("Extend") | ||
]), | ||
match1.captures) | ||
} | ||
|
||
runAllTests() |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,2 @@ | ||
if 'string_processing' not in config.available_features: | ||
config.unsupported = False | ||
config.unsupported = True |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -225,6 +225,7 @@ KNOWN_SETTINGS=( | |
swift-stdlib-experimental-hermetic-seal-at-link "0" "whether stdlib should be built with -experimental-hermetic-seal-at-link" | ||
swift-disable-dead-stripping "0" "turns off Darwin-specific dead stripping for Swift host tools" | ||
common-swift-flags "" "Flags used for Swift targets other than the stdlib, like the corelibs" | ||
swift-enable-experimental-string-processing "1" "whether to build experimental string processing feature" | ||
|
||
## FREESTANDING Stdlib Options | ||
swift-freestanding-flavor "" "when building the FREESTANDING stdlib, which build style to use (options: apple, linux)" | ||
|
@@ -1252,6 +1253,7 @@ LIBDISPATCH_SOURCE_DIR="${WORKSPACE}/swift-corelibs-libdispatch" | |
LIBDISPATCH_STATIC_SOURCE_DIR="${WORKSPACE}/swift-corelibs-libdispatch" | ||
LIBICU_SOURCE_DIR="${WORKSPACE}/icu" | ||
LIBCXX_SOURCE_DIR="${WORKSPACE}/llvm-project/libcxx" | ||
EXPERIMENTAL_STRING_PROCESSING_SOURCE_DIR="${WORKSPACE}/swift-experimental-string-processing" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do these sources need to be in a separate repo? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We plan to keep string processing in a package outside of the Swift repo for quicker development iterations and better modularity. The _MatchingEngine target is built both as a libswift library (used by the parser) and as a runtime library. When it gets closer to the release we can consider moving it into the Swift repo. Do you have concerns about this approach? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You should really keep that sources inside the swift repo. With "quicker development iteration", I guess you mean you want to avoid the overhead of the swift PR testing. But you'll have lit tests for that feature in the swift repo. This means, it will increase the probability that you'll break the swift lit tests. And that will add more troubles for everyone else. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We would integrate based on a tag, so we'd do integration testing the PR that updates the tag. Beyond that, it doesn't make senes to do full integration testing as part of a normal development cycle. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We have unit tests, functional tests, and integration tests. We use lit for integration testing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Still, I predict that this creates more troubles than it solves. |
||
|
||
# We cannot currently apply the normal rules of skipping here for LLVM. Even if | ||
# we are skipping building LLVM, we still need to at least build a few tools | ||
|
@@ -2196,6 +2198,14 @@ for host in "${ALL_HOSTS[@]}"; do | |
) | ||
fi | ||
|
||
if [[ $(true_false "${SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING}") == "TRUE" ]] ; then | ||
cmake_options=( | ||
"${cmake_options[@]}" | ||
-DSWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING:BOOL=TRUE | ||
-DEXPERIMENTAL_STRING_PROCESSING_SOURCE_DIR="${EXPERIMENTAL_STRING_PROCESSING_SOURCE_DIR}" | ||
) | ||
fi | ||
|
||
build_targets=(all "${SWIFT_STDLIB_TARGETS[@]}") | ||
if [[ $(true_false "${build_perf_testsuite_this_time}") == "TRUE" ]]; then | ||
native_swift_tools_path="$(build_directory_bin ${LOCAL_HOST} swift)" | ||
|
Uh oh!
There was an error while loading. Please reload this page.