Commit Graph

7 Commits

Author SHA1 Message Date
Rintaro Ishizaki
47f18d492e [ASTGen] Move regex literal parsing from SwiftCompilerSources to ASTGen
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.

Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
2023-11-16 10:59:23 -08:00
Doug Gregor
e263b0758a Ensure that there is at least one parse error in this test 2022-09-30 17:24:54 -07:00
Hamish Knight
50b01fa66f Merge pull request #59525 from hamishknight/watch-this-space 2022-06-28 22:41:34 +01:00
Hamish Knight
6c091a5dc2 [test] Re-enable forward-slash-regex-skipping-allowed.swift
Adjust to account for output differences between
asserts and non-asserts builds.

rdar://95806819
2022-06-24 13:49:42 +01:00
Andrew Trick
7849345fe3 Temporarily disable test/StringProcessing/Parse/forward-slash-regex-skipping-allowed.swift
Test fails after:
Merge pull request #59641 from hamishknight/no-skip-slash
Commit e610a69dac by github
2022-06-23 14:28:43 -07:00
Hamish Knight
8d59eb08df [Parse] Ban trailing space for /.../ regex literals
Ban space and tab as the last character of a
`/.../` regex literal, unless escaped with a
backslash. This matches the banning of space and
tab as the first character, and helps avoid breaking
source in even more cases.
2022-06-23 20:38:28 +01:00
Hamish Knight
515945fc6d [Parse] Avoid skipping bodies with /.../ regex literals
While skipping, if we encounter a token that looks
like it could be the start of a `/.../` regex
literal, fall back to parsing the function or type
body normally, as such a token could become a
regex literal. As such, it could treat `{` and
`}` as literal, or otherwise have contents that
would be lexically invalid Swift.

To avoid falling back in too many cases, we apply
the existing regex literal heuristics. Cases that
pass the heuristic fall back to regular parsing.
Cases that fail the heuristic are further checked
to make sure they wouldn't contain an unbalanced
`{` or `}`, but otherwise are allowed to be
skipped. This allows us to continue skipping for
most occurrences of infix and prefix `/`.

This is meant as a lower risk workaround to fix the
the issue, we ought to go back to handling regex
literals in the lexer.

Resolves rdar://95354010
2022-06-22 20:05:21 +01:00