Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Interface type of an archetype is not always represented by a
`SubstitutableType`, it could be a `DependentMemberType` as well.
The code in `IsDeclRefinementOfRequest::evaluate` already partially
accounts for that by using `getAs` but the nullptr check is missing
which means that the resulting substitution map is incorrect.
This should no longer be needed now that we check for a code
completion token when increasing the score. It should also
allow us to skip more conjunction elements, as that requires
the bit being set.
Skip type-checking multi-statement branches if the
completion is in a single-expression branch, and
skip type-checking the expression as a whole if
the completion is in a multi-statement branch.
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Introduce `ConstraintSystem::recordTypeVariablesAsHoles` as a
standard way to record that unbound type variables found in a
type are holes in the given constraint system.
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.
While producing a combined solution, let's reflect the number of
fixes and holes discovered in the conjunction, that way it would
be possible to filter solutions and keep track of the fact that
there were issues in the conjunction.
Since conjunction is not going to continue current solver path
after discovering an ambiguity, let's just mark all of the
unbound outer variables as placeholders to produce a complete solution.
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.
