A type variable can be fully bound by either an overload set (when
selecting an overload will provide a binding for the type variable) or
by a member constraint (when the base type is determined, the member
type will be known). This keeps the solver from making really, really
bad type variable bindings based on context information.
Swift SVN r5634
Move this computation into the "fixed" part of the scoring, because it
is not actually relative. Collapses the linear-time check down to a
constant-time check based on the locator.
Also, unify the constraint generation logic for all of the basic type
literals (integer, float, character, string) now that we have a common
mapping from expression to literal protocol.
Swift SVN r5590
Use this N-way solution "diff" when comparing two solutions to
determine which is better. No actual functionality change here,
because we're still not comparing overload choices.
Swift SVN r5518
Set up constraints for AssignExprs within the constraint system instead of using typeCheckAssignment to set up their own isolated system. Kill the goofy hack not to consider a single-AssignExpr closure to be single-expression-body, because single-assign-expr-body closures now type-check successfully.
typeCheckAssignment still lingers because of a couple uses in typeCheckConstructorBody, but those should be easy to kill off next.
Swift SVN r5504
This eliminates the last of the old "convert literal to specific type"
code, as all of the basic literal kinds now go directly through formal
protocols. One minor casualty of this change is that we've lost the
"integer constant too large" warning. Filed as
<rdar://problem/14070127>, which is likely to be addressed in SIL.
Swift SVN r5477
Thread the current DeclContext down into expression type-checking so that we will be able to set up ImplicitClosureExprs with the right parent context. (Don't actually set the right decl context when creating an ImplicitClosureExpr yet, since IRGen isn't quite ready to handle specialized partial applications and crashes on the emitted SIL if we do.)
Swift SVN r5431
Add a version of TypeChecker::typeCheckExpression() that performs a
"shallow" type-check of just the top-level expression, rather than a
"deep" type-check of the full expression. Use it to eliminate
TypeChecker::semaApplyExpr().
Swift SVN r5394
We were generating constraints from a slightly different expression
than we were applying the constraints to, which could produce odd
crashes. Be more principled about using the modified expression.
Swift SVN r5384
If we fail to find a solution, solve the system again and track the
remaining failures. Provides a 13% improvement in the time to parse
swift.swift.
Swift SVN r5344
The former should always be recorded, because they are always
reported, and require far less effort to report. The latter can be
lazily computed (only when we found no solution and no unavoidable
failures) and will require far more work to diagnose. No functionality
change.
Swift SVN r5340
This eliminates tracking of type variable bindings we've made during
initial constraint generation, where we wouldn't ever undo those
changes anyway.
Swift SVN r5337
When we're trying to convert one tuple to another, and we hit a
problem that doesn't require us to actually perform more type
comparisons (mismatched labels, not enough elements, etc.), fall back
to attempt a scalar-to-tuple conversion when the target tuple can be
initialized by a scalar.
This is *not* a complete solution to this problem. It handles the
obvious cases, but for the non-obvious cases we'll have to pursue both
paths separately to see which one pans out.
Nonetheless, this fixes most of <rdar://problem/11293232>, as well as
<rdar://problem/13820721> and <rdar://problem/13394261>.
Swift SVN r5295
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
