The new constraint solver is very close to providing parity with the
old solver, and is significantly faster, so cut over to the new
solver. There are minor adjustments to two tests: one where we're
losing sugar (Int becomes Int64) and another where our ignorance of
overload resolution means we don't reject something silly that we
should.
Note that this only affects the *solver* component of the
constraint-based type checker; we haven't completely obsoleted the old
type checker yet.
Swift SVN r5281
We'll want to rework the way simplification processes and retires
constraints, but it's easier to do once the old solver is gone. Down
to four failures with the new constraint checker as the default.
Swift SVN r5279
This solver handles most of what the old solver does (enabling it by
default only causes 9 test failures), but is radically simpler and
already significantly faster (~50% slower than the old-old type
checker on swift.swift). There are some egregious hacks here to still
be eliminated (see FIXMEs), but it's a start.
Swift SVN r5272
This eliminates the use of
TypeChecker::substBaseForGenericTypeMember() from constraint
application, which relies on the existing type checker's
isCoercibleToType(). The standalone version is a bit cleaner.
Swift SVN r5156
Introduce the LogicValue protocol, which is used to establish when a
particular type can be used as a logical value in a condition. Make
Bool conform to this protocol.
Rename the Builtin.i1-returning Bool.getLogicValue() to
_getBuiltinLogicValue(), because this is meant to be a builtin hook
for the compiler. We can add more underscores here if needed to hide
this further from users.
Move the implementation of _getBool() into C code. It was performing
an 'if' on a Builtin.i1, which does not (and should not!) conform to
the LogicValue protocol. Once more oneof IR generation comes online,
we'll be able to write both this and _getBuiltinLogicValue in Swift
directly.
Swift SVN r5140
As part of exercising this, tighten up the handling of user-defined
conversions: we always need to find an overload choice in the solution
that tells us what conversion function to use. Fix some
locator-synchronization issues between constraint generation and
constraint application; these need to match up exactly.
Swift SVN r5104
We need more of the facilities of ExprRewriter to handle user-defined
conversions. This is a step in that direction. No functionality
change.
Swift SVN r5098
Start factoring out the logic that computes the mapping from one tuple
type to another. We're only using it in one place now (the
tuple-to-tuple coercion), but it should be picked up by the constraint
checker's type-matching code.
Also, fix the temporary statistics covering how much is going through
the old coercion code. With this change, we're only missing 40 of 4548
of the coercions in swift.swift (all of which appear to be string
interpolations, function type conversions, or user-defined
conversions).
Swift SVN r5087
This eliminates some boilerplate from the call sites where addTypeMemberConstraint is used correctly, fixes bugs where it isn't (viz. in openType, where we were matching secondary archetypes to the metatype types of the associated types rather than to the associated types themselves), and should prevent the same class of bug from being introduced by new type member constraint generators.
Swift SVN r5041
The five parts are:
- Support code and high-level entry points
- Constraint generation
- Constraint solving
- Constraint application
- Diagnostics
No functionality change.
Swift SVN r4447
