Instead of asking SILGen to build calls to `makeIterator` and
`$generator.next()`, let's synthesize and type-check them
together with the rest of for-in preamble. This greatly simplifies
interaction between Sema and SILGen for for-in statements.
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.
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.
- 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).
Introduce the ArgumentList type, which represents
a set of call arguments for a function or
subscript. This will supersede the use of tuple
and paren exprs as argument lists.
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
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]
- Allow named opaque types in typed patterns and subscripts
- Fix inheritance clause printing for `GenericParamList`
- clang-format changes from previous commit on this branch
In order to put constraints on opaque types in function returns, we want to
support naming them like 'func f() -> <T> T { }'. This commit parses that
syntax into the new `OpaqueReturnParameteriedTypeRepr`. This is hidden behind
the new flag --enable-experimental-opaque-return-types.
Previously we were walking them once when visiting
the capture list, and then again as a part of the
pattern binding decl. Change the logic to only
visit them as a part of their pattern binding decl.
`visitTopLevelCodeDecl` ignored the `Stmt` visit returning a nullptr.
This caused the `walkToDeclPost` to run for the `TopLevelCodeDecl` and
thus an imbalance in the `RangeResolver` pre and posts (since none of
the children would have their `walkTo*Post` called).
This was originally incorrectly fixed while assuming that the
`walkTo*Post` are called regardless of whether the children were visited
or not. Those changes have been reverted - fixing an imbalance in
`ExtDecls` in `SemaAnnotator`.
Added a test case for the `ExtDecls` imbalance which can occur while an
extension is being added.
Resolves rdar://74820040
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
bindSwitchCasePatternVars() was introduced as a simpler way to wire up
the "parent" links for case variables with same-named case variables
from the previous case item, and is used in the function builders code
to handle switch statements. It duplicated some logic from the
statement checker that did the same thing using a more complicated
algorithm.
Switch (ha ha) the logic in the statement checker over to using
bindSwitchCasePatternVars(), fixing a bug involving unresolved
patterns along the way, and remove the old code that incrementally
wired up the parent links. The resulting code is simpler and is
unified across the various code paths.
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
Add a new GenericContext::getParsedGenericParams(). This produces
the same value as GenericContext::getGenericParams() if the generic
parameter list was written in source. For extensions and protocols,
this returns nullptr without synthesizing anything.
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
