Models `PackExpansionType` as a type variable that can only
bind to `PackExpansionType` and `expansion of` constraint that
connects expansion variable to its pattern, shape types.
* Use fancy arrows (`→`) because they are distinct from and shorter than `->`,
and fancier.
* We have two ways of demarcating locators: `@ <locator>` and `[[<locator>]];`.
Stick to the first, which is shorter and clearer.
* 'attempting type variable' → 'attempting binding'. *Bindings* are attempted,
not type variables.
* `considering ->` → `considering:`. I think a colon is semantically more fit
and makes things easier to read if the considered constraint has arrows in its
description or types. It’s also shorter this way.
Fixes a bug where only pack environments created during constraint
would be usable during solution application, everything else would
create a new environment that would produce pack elements with new
UUIDs which cases issues during SILGen.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Currently solver picks the first conjunction it can find,
which means - the earliest resolved closure. This is not
always correct because when calls are chained closures
passed to the lower members could be resolved sooner
than the ones higher up but at the same time they depend
on types inferred from members higher in the chain.
Let's make sure that multi-statement closures are always
solved in order they appear in the AST to make sure that
types are available to members lower in the chain.
When doing solver-based cursor info, we’ll type check the expression in question using a normal `typeCheckASTNodeAtLoc` call (not in code completion mode) and listen for any solutions that were produced during the type check.
If a (partial) solution has a type variable it could only be unbound
if `FreeTypeVariableBinding` is set to `Allow`, in all other cases
solution would either have a fully resolved type or a hole.
`applySolution` shouldn't second guess `finalize()` and just apply
a solution as given. This is very important for multi-statement closures
because their elements are solved in isolation and opaque value types
inferred for their result could contain not-yet-resolved type variables
from outer context in their substitution maps (which it totally legal
under bi-directional inference).
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
Solver can now handle multiple different targets e.g. multi-statement
closures, result builders etc. So it's more appropriate to say that
the constraint system is too complex.
We record fixes while solving normal expressions for code completion and we should do the same when solving result builders if we are reporting the solutions to completion callbacks.
Some implicit calls to `.callAsFunction` require that a new root
expression to be created for them in order to record argument list
and resolved overload choice.
It's always been the case that partial solutions introduce
some storage duplication when applied back to the constraint
system to form a more complete solution with outer context,
but the constraint systems used to be small before
introduction of result builders (and now multi-statement
inference), which make the duplication more visible.
When a closure is provided with a contextual type that has isolated
parameters, infer that the corresponding closure parameter is "isolated".
Fixes rdar://83732479.
Attempting to pre-compute a set of referenced type variables
upfront is incorrect because parameter(s) and/or result type
could be bound before conjunction is attempted. Let's compute
a set of referenced variables before each element gets attempted.
