Fix SR-718: Type mismatch reported as extraneous parameter

The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.

CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.

The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr.  This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
This commit is contained in:
Chris Lattner
2016-02-12 17:17:19 -08:00
parent df62c78f11
commit cf2e7f6f45
14 changed files with 297 additions and 303 deletions

View File

@@ -456,8 +456,6 @@ StringRef Fix::getName(FixKind kind) {
return "fix: tuple-to-scalar";
case FixKind::ScalarToTuple:
return "fix: scalar-to-tuple";
case FixKind::RelabelCallTuple:
return "fix: relabel call tuple";
case FixKind::OptionalToBoolean:
return "fix: convert optional to boolean";
case FixKind::FromRawToInit: