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
