- Frontend: Implicitly import `_StringProcessing` when frontend flag `-enable-experimental-string-processing` is set.
- Type checker: Set a regex literal expression's type as `_StringProcessing.Regex<(Substring, DynamicCaptures)>`. `(Substring, DynamicCaptures)` is a temporary `Match` type that will help get us to an end-to-end working system. This will be replaced by actual type inference based a regex's pattern in a follow-up patch (soon).
- SILGen: Lower a regex literal expression to a call to `_StringProcessing.Regex.init(_regexString:)`.
- String processing runtime: Add `Regex`, `DynamicCaptures` (matching actual APIs in apple/swift-experimental-string-processing), and `Regex(_regexString:)`.
Upcoming:
- Build `_MatchingEngine` and `_StringProcessing` modules with sources from apple/swift-experimental-string-processing.
- Replace `DynamicCaptures` with inferred capture types.
With `-enable-experimental-string-processing`,
start lexing `'` delimiters as regex literals (this
is just a placeholder delimiter for now). The
contents of which gets passed to the libswift
library, which can return an error string to be
emitted, or null for success.
The libswift side isn't yet hooked up to the Swift
regex parser, so for now just emit a dummy
diagnostic for regexes starting with quantifiers.
If successful, build an AST node which will be
emitted as an implicit call to an
`init(_regexString:)` initializer of an in-scope
`Regex` decl (which will eventually be a known
stdlib decl).
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
Despite being otherwise disconnected from the
constraint system, it's possible for it to affect
how we type-check tuple matches in certain cases.
This is due to the fact that:
- It can have a lower type variable ID than an
opened generic parameter type, so becomes the
representative when merged with it. And because it
has a different locator, this can influence
binding prioritization.
- Tuple subtyping is broken, as it's currently a
*weaker* relationship than conversion.
Therefore, temporarily restore this bit of logic
for language versions < 6. If possible, we should
try and fix tuple subtying in Swift 6 mode to not
accept label mismatches, so that it's not more
permissive than tuple conversion.
rdar://85263844
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
Previously this check was guarding against this
case, however with the argument list refactoring,
it's now possible for regular tuples to have
ApplyExpr parents. As such, broaden the check to
handle any tuple expr.
if the expression is an argument to `#selector`.
For `#selector` arguments, functions and properties are syntactically distinct
with the getter/setter label, so the solver should not unconditionally prefer
properties to unapplied functions. A better fix for this is to port over the
`#selector` diagnostics from CSApply, and not attempt invalid disjunction choices
based on the selector kind on the valid code path.
Previously we were introducing a type variable
to mark a constructor's parameter list as
`TVO_PrefersSubtypeBinding`. Unfortunately this
relies on representing the parameter list as a
tuple, which will no longer be properly supported
once param flags are removed from tuple types.
Move the logic into CSRanking such that we pick up
and compare the parameter lists when comparing
overload bindings. For now, this still relies on
comparing the parameter lists as tuples, as there's
some subtle tuple subtyping rules that could
potentially affect source compatibility here, but
at least we can explicitly strip the parameter
flags and localise the hack to CSRanking rather
than exposing it as a constraint.
Use this new element to represent the overload type
for a constructor call, and have it store a bit
indicating whether the call is for a short-form
`X(...)` or self-delegating `self.init(...)` call.
Tuple splat/implosion is (still) allowed for patterns (with a warning in Swift 5)
so we need to use `SingleApply` while looking up members to make sure that e.g.
`case test(x: Int, y: Int)` gets the labels preserved when matched with
`case let .test(tuple)` and `Compound` when associated values form a tuple pattern.
- Make sure that `varType` is wrapped into an optional type for `weak`
declarations.
- Verify that `externalPatternType` is an optional type when one-way
constraints are requested.
parameter attributes for closure parameters.
For regular function parameters, these constraints will have already been
generated and solved when computing the backing property wrapper type at
the function declaration. If the solver also generates these constraints
when type checking a function call, it leads to misleading diagnostics
about an argument mismatch that will appear at the function declaration
instead of the call-site.
Instead of passing pattern directly, let's fetch it from the pattern
binding and remove extra argument from `SolutionApplicationTarget::forUninitializedVar`.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
