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
