These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Allow `LinkedExprAnalyzer` to capture `??` operator and walk into
its arguments because they could have valuable type information,
but don't attempt to favor or link operators if `??` is present in a chain.
Resolves: rdar://85277993
This will let us find the test file that produced a failure on the first attempt, saving the project at least three trillion cumulative person-seconds each year.
This test disables access controls, and it mistakenly used the Concurrency module's version of `_internalInvarant` instead of the Standard Library's version.
Previously, when we reached the maximum nesting level, we changed the current token’s kind to an EOF token. A lot of places in the parser are not set up to expect this token change. The intended workaround was to check whether pushing a structure marker failed (which would change the token kind) and bail out parsing if this happened. This was fragile and caused assertion failures in assert builds.
Instead of changing the current token’s kind, and failing to push the structure marker, let the lexer know that it should cut off lexing, essentially making the input buffer stop at the current position. The parser will continue to consume its current token (`Parser.Tok`) and the next token that’s already lexed in the lexer (`Lexer.NextToken`) before reaching the emulated EOF token. Thus two more tokens are parsed than before, but that shouldn’t make much of a difference.
exponential behavior.
Binding value types early allows the previous version of this test
to compile, but the performance still doesn't scale with a few more
operands in the + chain.
If a type variable has a subtype binding which came from a conversion/subtype/equality
constraint to a struct or enum (expect to `AnyHashable`, `Unsafe{Mutable}RawPointer`),
attempt it early because that type is the only choice which is not going to fail such
constraint.
For example, in cases like `$T argument convertible to Int` type variable could
only be bound to `Int`, `Int!`, or `@lvalue Int` to satisfy that constraint, so
it would make sense to attempt to bind it to `Int` early if it doesn't represent
a result of a member lookup (that's how IUO and/or `@lvalue` could be inferred)`
and doesn't have any direct disjunction associated with it e.g. for coercion or
optional matching.
`init` calls to redeclared types would end up diagnosed as ambiguity,
so locator simplification needs to account for the fact that "base"
of constructor might be overloaded type reference.
Resolves: rdar://84879566
