A member reference to a function with a dynamic 'Self' result type
can introduce a covariant return expression into the AST. This is
exposed by the (already deeply cursed) -self method on NSObject(Protocol).
Add a regression test and said cursed member to the mock SDK.
Represent this in much the same way that collections do by creating an opaque value representing the source argument, and a conversion expression representing the destination argument.
When parsing a regular expression literal, accept a serialized capture structure from the regex parser. During type checking, decode it and form Swift types.
Examples:
```swift
'/(.)(.)/' // ==> `Regex<(Substring, Substring)>`
'/(?<label>.)(.)/' // ==> `Regex<(label: Substring, Substring)`
'/((.))*((.)?)/' //==> `Regex<([Substring], [Substring], Substring, Substring?)>`
```
Also:
- Fix a bug where a regex literal parsing error is not returning an error parser result.
Note:
- This needs to land after apple/swift-experimental-string-processing#92 and after `dev/4` tag has been created.
- See apple/swift-experimental-string-processing#92 for regex parser changes and the capture structure encoding.
- The `RegexLiteralParsingFn` `CaptureStructureOut` pointer type change from `char *` to `void *` will not break builds due to implicit pointer conversion (SE-0324) and unchanged ABI.
Resolves rdar://83253511.
This reverts commit a67a0436f7, reversing
changes made to 9965df76d0.
This commit or the earlier commit this commit is based on (#40531) broke the
incremental bot.
Update the lexing implementation to defer to the
regex library, which will pass back the pointer
from to resume lexing, and update the emission to
call the new `Regex(_regexString:version:)`
overload, that will accept the regex string with
delimiters.
Because this uses the library's lexing
implementation, the delimiters are now `'/.../'`
and `'|...|'` instead of plain `'...'`.
Pack expressions take a series of argument values and bundle them together as a pack - much like how a tuple expression bundles argument expressions into a tuple.
Pack reification represents the operation that converts packs to tuples/scalar types in the AST. This is important since we want pack types in return positions to resolve to tuples contextually.
Use this to enable better detection of async contexts when determining
whether to diagnose problems with concurrency.
Part of SR-15131 / rdar://problem/82535088.
- 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).
Instead of tracking the single-expression closures in a separate
structure and passing that in under the right conditions, it makes more
sense to simply set the 'Where' decl context to the single-expr closure
and use the correct declaration context to determine whether the context
is async. The reduces the number of variables that need to get plumbed
through to the actual unavailable-from-async check and simplifies the
actual check from figuring out whether we're in a single-expr closure or
in an async context.
Now that the CSApply just uses components, we can
better split up the key path constructors to either
accept a set of resolved components, or a parsed
root or path.
This was a hack needed to let CSApply re-write
IUO-returning applies, and is no longer needed now
that we can directly perform the unwrapping when
needed.
With the introduction of the ArgumentList type,
argument expressions will be direct decedents of
call expressions, without an intermediate TupleExpr.
As such, we need to tweak isValidTypeExprParent to
consider the child expression such that `T(x)` is
permissible, but `x(T)` is not.
Change isValidTypeExprParent to take a child expr
parameter, and update its use in MiscDiagnostics
and PreCheckExpr. For PreCheckExpr, switch from a
stack to walking the parent directly, as a
stack-based approach would be a bit more fiddly in
this case, and walking the parents shouldn't be
expensive.
This should be NFC, I'm splitting it off from the
ArgumentList refactoring to make the rebasing there
a little more straightforward.
Many, many, many types in the Swift compiler are intended to only be allocated in the ASTContext. We have previously implemented this by writing several `operator new` and `operator delete` implementations into these types. Factor those out into a new base class instead.
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
