Associate potential bindings with a constraint graph node and
start keeping track of added and removed constraints.
This is not a complete implementation because the ability to
infer bindings transitively is missing.
Binding inference requires constraint propagation through to referenced
type variables, in current "fixed bindings" storage mode it is impossible
to figure out whether tracked type variables are referenced by or from
a type variable.
Splitting storage for referenced by/from also helps to provide more
meaningful debug output and make sure there are no attempts to insert
duplicate references.
Currently the pattern is to collect the type variables and then unique
them. Instead of asking clients to do uniquing, let's just accept a set
as an argument.
Edge contraction was being performed for Bind, Equal,
BindToPointerType, and BindParam constraints. However, it's behavior
on everything but BindParam is the same as what matchTypes() already
does, so only look at BindParam constraints. This simplifies the code
but shouldn't change its behavior.
Since bindings now require finalization we need a new endpoint
which perform all of the required actions before returning complete
`PotentialBindings` object when they are requested for a particular
type variable without any other context.
Previously we would only gather one-way constraints
if they were found through a type variable in their
right hand side. However we would incorrectly check
this against the type variable that we started the
search at. This meant that if the constraint was
found through a fixed binding, we would never
return it, and could therefore fail to re-activate
it, leaving it unsolved.
Fix this issue by simply removing the check for
the RHS, and letting the constraint system handle
it instead.
Resolves rdar://64890308.
Holes couldn't be contracted instead solving of the constraint
has to be delayed until one of the sides is bound to a type,
otherwise there is a risk to loose contextual information.
The only caller was `contractEdges`, which would
only call it with constraints from either the
active or inactive list. The implementation can
therefore be replaced by
`ConstraintSystem::retireConstraint`, and
`removeGeneratedConstraint` can also be removed.
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Start visiting transitive fixed bindings for type
variables, and stop visiting adjacencies for
`gatherConstraint`'s `AllMentions` mode.
This improves performance and fixes a correctness
issue with the old implementation where we could
fail to re-activate a coercion constraint, and
then let invalid code get past Sema, causing
either miscompiles or crashes later down the
pipeline.
Unfortunately this change requires us to
temporarily drop the non-ephemeral fix for a couple
of fairly obscure cases where the overload hasn't
yet been resolved. The logic was previously relying
on stale adjacency state in order to re-activate
the fix when the overload is bound, but it's not
connected on the constraint graph. We need to find
a way to connect constraints to unresolved
overloads they depend on.
Resolves SR-12369.
An awful pattern we use throughout the compiler is to save and restore global flags just for little things. In this case, it was just to turn on some extra options in AST printing for type variables. The kicker is that the ASTDumper doesn't even respect this flag. Add this as a PrintOption and remove the offending save-and-restores.
This doesn't quite get them all: we appear to have productized this pattern in the REPL.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
This reinstates the use of direct adjacency information when gathering
constraints, effectively reverting
54bdd7b840.
Fixes the regression that commit caused, which is tracked by
rdar://problem/54274245.
Reinstate the list of adjacencies in each constraint graph node,
effectively reverting
dfdd352d3d. Exclude one-way constraints
from this computation; we'll handle them separately.
One-way constraint expressions, which are the only things that
introduce one-way constraints at this point, want to look through
lvalue types to produce values. Rename OneWayBind to OneWayEqual, map
it down to an Equal constraint when it is simplified (to drop
lvalue-ness), and apply that coercion during constraint application.
Part of rdar://problem/50150793.
There were a few places where we wanted fast testing to see whether a
particular type variable is currently of interest. Instead of building
local hash tables in those places, keep type variables in a SetVector
for efficient testing.
We only care about gathering a one-way constraint if (1) the left-hand
side is in the set of type variables we care about now, and (2) the
type variable we started from is in the right-hand side.
When we encounter a cycle in the one-way component graph due to constraints
that (e.g.) tie together the outputs of two one-way constraints, collapse
the components along the cycle into a single connected component, because
all of those type variables must be solved together.
Introduce the notion of "one-way" binding constraints of the form
$T0 one-way bind to $T1
which treats the type variables $T0 and $T1 as independent up until
the point where $T1 simplifies down to a concrete type, at which point
$T0 will be bound to that concrete type. $T0 won't be bound in any
other way, so type information ends up being propagated right-to-left,
only. This allows a constraint system to be broken up in more
components that are solved independently. Specifically, the connected
components algorithm now proceeds as follows:
1. Compute connected components, excluding one-way constraints from
consideration.
2. Compute a directed graph amongst the components using only the
one-way constraints, where an edge A -> B indicates that the type
variables in component A need to be solved before those in component
B.
3. Using the directed graph, compute the set of components that need
to be solved before a given component.
To utilize this, implement a new kind of solver step that handles the
propagation of partial solutions across one-way constraints. This
introduces a new kind of "split" within a connected component, where
we collect each combination of partial solutions for the input
components and (separately) try to solve the constraints in this
component. Any correct solution from any of these attempts will then
be recorded as a (partial) solution for this component.
For example, consider:
let _: Int8 = b ? Builtin.one_way(int8Or16(17)) :
Builtin.one_way(int8Or16(42\
))
where int8Or16 is overloaded with types `(Int8) -> Int8` and
`(Int16) -> Int16`. There are two one-way components (`int8Or16(17)`)
and (`int8Or16(42)`), each of which can produce a value of type `Int8`
or `Int16`. Those two components will be solved independently, and the
partial solutions for each will be fed into the component that
evaluates the ternary operator. There are four ways to attempt that
evaluation:
```
[Int8, Int8]
[Int8, Int16]
[Int16, Int8]
[Int16, Int16]
To test this, introduce a new expression builtin `Builtin.one_way(x)` that
introduces a one-way expression constraint binding the result of the
expression 'x'. The builtin is meant to be used for testing purposes,
and the one-way constraint expression itself can be synthesized by the
type checker to introduce one-way constraints later on.
Of these two, there are only two (partial) solutions that can work at
all, because the types in the ternary operator need a common
supertype:
[Int8, Int8]
[Int16, Int16]
Therefore, these are the partial solutions that will be considered the
results of the component containing the ternary expression. Note that
only one of them meets the final constraint (convertibility to
`Int8`), so the expression is well-formed.
Part of rdar://problem/50150793.
Move the logic for creating connected components of orphaned
constraints into the connected-components algorithm code, rather than
making it a special part of SplitterStep.
Maintain the order of constraints when splitting the system into
connected components, to match the behavior prior to the refactoring
into a separate connected-components algorithm.
Have the constraint graph's connected-component implementation be more
self-contained, producing a vector containing each of the actual
components (where each is defined by a list of type variables and a list
of constraints). This simplifies the contract with the client
(SplitterStep) and eliminates a bunch of separate mapping steps to
interpret the results.
It also lets us enrich the Component data structure in the future.
The connected components computation was not forming components when all of
the type variables in a component were already bound. Any remaining
constraints involving those type variables would then arbitrarily end up
in component 0, due to the the default-construction behavior of a map’s
operator[] with missing keys, artificially increasing the size of that
component with (typically) additional disjunctions.
Ensure that all constraints get into a component, creating one to hold
the a constraint even when all of the type variables are already bound.
Then, assert the invariant that every constraint is associated with a
component.
In time, we should probably eliminate this notion of disjunctions that
remain even when the type variable has been bound. For now, strengthen the
invariant to at least ensure that they get solved in isolation.
