We're not planning on removing the splitter because it is a big win
in some cases, but we want to run it less often since it can also
be a source of overhead. This flag allows us to compare performance
to understand the tradeoffs better.
Also introduce two new frontend flags:
The -solver-scope-threshold flag sets the maximum number of scopes, which was
previously hardcoded to 1 million.
The -solver-trail-threshold flag sets the maximum number of trail steps,
which defaults to 64 million.
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.
