In cases where we have multiple designated types, sort the types that
were designated for this operator based on any information we can
gather about actual argument types at usage sites.
We can consider extending this further in a future commit to ignore
designated types when we have concrete type information that we are
confident of.
This counts the number of leaf scopes we reach while solving the
constraint sytem, and is a much better measure of the growth of
unnecessary work than the total number of scopes opened.
There were two tests where I had a difficult time getting scale-test
to fit the curve even after adjusting some of the parameters, so I've
left those to use the old stat for now.
Have the constraint solver consider multiple designated types for an
operator. We currently consider the overloads from each in turn,
stopping as soon as we have a solution. As a result, we can still end
up with exponential type checking in some cases if an operator has
more than a single designated type. This still allows us to reduce the
base of that exponent, though, which makes it possible to increase the
number of expressions we can type check successfully in practice.
Currently (with or w/o failures) constraint system is not returned
back to its original state after solving, because constraints from
initial "active" list are not returned to the system. To fix that
let's allocate "initial" scope which captures state right before
solving begins, and add "active" list to the solver state to capture
information about "active" constraints at the time of its creation.
This is follow-up to https://github.com/apple/swift/pull/19873
Add parsing, type checking, serialization, and deserialization support
for specifying multiple types as "designated" for operator lookup for
a given operator declaration.
The constraint solver still considers only the first type when
deciding the order to attempt the elements of a disjunction, so this
doesn't really change behavior yet.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
For operators with default implementations in an extension, we don't
want to typecheck it both with overloads from the protocol type and
the ones from the extension.
For now this is only used for the same purpose as the previous type
constraint walking utility function.
Eventually we can incorporate this into our selection of overload
choices.
Use the type designated in the operator declaration as a mechanism to
limit the exploration we do in constraint solving. If we can find a
solution with an overload defined within that type or an extension of
that type, we do not look at any of the other options in the
disjunction.
This is disabled by default, and enabled with
> `-swift-version 5 -Xfrontend -solver-enable-operator-designated-protocols`
This will minimize the chance of breaking code. Currently SwiftLint
has one "too complex" expression with this change. Further changes to
the solver may improve that situation, and potentially allow us to
move this out from -swift-version 5 if we're willing to take the risk
of breaking some code as a result.
Because binding producer is going to attempt to unwrap optionals
and try the type, which would lead to infinite recursion because
dependent member types aren't bindable.
Resolves: rdar://problem/44770297
Attempt to visit disjunctions that are associated with applies where
we have at least some useful information about the types of all of the
arguments before visiting other disjunctions.
Two tests here got faster, and one slightly slower. One of the
faster tests is actually moving from test/ to the slow/ directory in
validation-test because despite going from 16s to less than 1s, it was
still borderline for what we consider the slow threshold, so I made
the test more complex. The one that got a little slower is
rdar22022980, which I also made more complex so that it is clearly
"slow" by the way we are testing it.
slower:
rdar22022980.swift
faster:
rdar33688063.swift
expression_too_complex_4.swift
Instead of asserting in the solver loop, let's move all of that
logic into `SolverStep::transitionTo(StepState)` and verify state
transition validity there.
Instead of using `TypeChecker` and related APIs directly every time,
let's just abstract it all away to easily check if solver is running
in debug mode and to produce indented logger.
First of all, let the splitter transfer constraints from inactive
work-list to associated components. Also start tracking components
to reinstate constraints back to constraint system when everything
is done, this allows to execute component steps in any desirable order.
Introduce a notion of `StepState` with some valid transitions,
and split monolithic `take(bool)` into three phases - `setup`, `take`, and
`resume`.
* `setup` - is preliminary state before the step has been taken
for the first time.
* `take` - represents actual logic of the step, results in either
step being done or suspended.
* `resume` - `take` might split steps into smaller ones to make
incremental progress towards the target, which means
that the main step has to be suspended. `resume` is
triggered when all of the "follow-up" steps have been
executed and are "done".
`DisjunctionStep` attempts all of the viable choices,
at least one of the choices has to succeed for disjunction
to be considered a success.
`DisjunctionStep` attempts each choice and generates followup
`SplitterStep` to see if applying choice to constraint system
resulted in any simplification.
Failure propagation is crucial for splitter and component steps
because that's the only signal for them to figure out if they
could be completely solved or have to fail.
For example, if one of the component steps created by "split"
fails it would cascade to the rest of the pending component steps
receiving "fail" signal and ultimately result in failure of the
"split" when it's re-taken.
* `SplitterStep` is responsible for running connected components
algorithm to determine how many independent sub-systems there are.
Once that's done it would create one `ComponentStep` per such
sub-system, and move to try to solve each and then merge partial
solutions produced by components into complete solution(s).
* `ComponentStep` represents a set of type variables and related
constraints which could be solved independently. It's further
simplified into "binding" steps which attempt type variable and
disjunction choices.
* "Binding" steps such as `TypeVariableStep` and `DisjunctionStep`
are responsible for trying type binding choices in attempt to
simplify the system and produce a solution. After attempting each
choice they introduce a new "split" step to compute more work.
The idea so to split solving into non-recursive steps,
represented by `SolverStep`, each of the steps is resposible
for a unit of work e.g. attempting type variable or
disjunction bindings/choices.
Each step could produce more work via "follow-up" steps,
complete "partial" solution when it's done, or error which
terminates solver loop.
* Extract logic for attempting individual choices into `solveForDisjunctionChoice`
* Remove all of the unnecessary information from `DisjunctionChoice`
* Convert auxiliary logic to operate on `TypeBinding` instead of `DisjunctionChoice`
