[Diagnostics] NFC: Remove obsolete diagnoseContextualConversionError

Author: xedin

lib/Sema/CSDiag.cpp

@@ -195,12 +195,6 @@ class FailureDiagnosis :public ASTVisitor<FailureDiagnosis, /*exprresult*/bool>{
   /// Emit an ambiguity diagnostic about the specified expression.
   void diagnoseAmbiguity(Expr *E);
 
-  /// Attempt to produce a diagnostic for a mismatch between an expression's
-  /// type and its assumed contextual type.
-  bool diagnoseContextualConversionError(Expr *expr, Type contextualType,
-                                         ContextualTypePurpose CTP,
-                                         Type suggestedType = Type());
-
 private:
   /// Validate potential contextual type for type-checking one of the
   /// sub-expressions, usually correct/valid types are the ones which
@@ -500,51 +494,6 @@ DeclContext *FailureDiagnosis::findDeclContext(Expr *subExpr) const {
   return finder.DC;
 }
 
-bool FailureDiagnosis::diagnoseContextualConversionError(
-    Expr *expr, Type contextualType, ContextualTypePurpose CTP,
-    Type suggestedType) {
-  // If the constraint system has a contextual type, then we can test to see if
-  // this is the problem that prevents us from solving the system.
-  if (!contextualType)
-    return false;
-
-  // Try re-type-checking the expression without the contextual type to see if
-  // it can work without it.  If so, the contextual type is the problem.  We
-  // force a recheck, because "expr" is likely in our table with the extra
-  // contextual constraint that we know we are relaxing.
-  TCCOptions options = TCC_ForceRecheck;
-  if (contextualType->is<InOutType>())
-    options |= TCC_AllowLValue;
-
-  auto *recheckedExpr = typeCheckChildIndependently(expr, options);
-  auto exprType = recheckedExpr ? CS.getType(recheckedExpr) : Type();
-
-  // If there is a suggested type and re-typecheck failed, let's use it.
-  if (!exprType)
-    exprType = suggestedType;
-
-  // If it failed and diagnosed something, then we're done.
-  if (!exprType)
-    return CS.getASTContext().Diags.hadAnyError();
-
-  // If we don't have a type for the expression, then we cannot use it in
-  // conversion constraint diagnostic generation.  If the types match, then it
-  // must not be the contextual type that is the problem.
-  if (isUnresolvedOrTypeVarType(exprType) || exprType->isEqual(contextualType))
-    return false;
-
-  // Don't attempt fixits if we have an unsolved type variable, since
-  // the recovery path's recursion into the type checker via typeCheckCast()
-  // will confuse matters.
-  if (exprType->hasTypeVariable())
-    return false;
-
-  ContextualFailure failure(
-      CS, CTP, exprType, contextualType,
-      CS.getConstraintLocator(expr, LocatorPathElt::ContextualType()));
-  return failure.diagnoseAsError();
-}
-
 //===----------------------------------------------------------------------===//
 // Diagnose assigning variable to itself.
 //===----------------------------------------------------------------------===//
@@ -1256,13 +1205,6 @@ void ConstraintSystem::diagnoseFailureFor(SolutionApplicationTarget target) {
     if (diagnosis.diagnoseExprFailure())
       return;
 
-    // If this is a contextual conversion problem, dig out some information.
-    if (diagnosis.diagnoseContextualConversionError(
-            expr,
-            getContextualType(expr),
-            getContextualTypePurpose(expr)))
-      return;
-
     // If no one could find a problem with this expression or constraint system,
     // then it must be well-formed... but is ambiguous.  Handle this by diagnostic
     // various cases that come up.

test/Constraints/closures.swift

@@ -456,7 +456,13 @@ extension Collection {
   }
 }
 func fn_r28909024(n: Int) {
-  return (0..<10).r28909024 { // expected-error {{unexpected non-void return value in void function}}
+  // FIXME(diagnostics): Unfortunately there is no easy way to fix this diagnostic issue at the moment
+  // because the problem is related to ordering of the bindings - we'd attempt to bind result of the expression
+  // to contextual type of `Void` which prevents solver from discovering correct types for range - 0..<10
+  // (since both arguments are literal they are ranked lower than contextual type).
+  //
+  // Good diagnostic for this is - `unexpected non-void return value in void function`
+  return (0..<10).r28909024 { // expected-error {{expression type 'Range<Int>.Index' (aka 'Int') is ambiguous without more context}}
     _ in true
   }
 }

test/Parse/matching_patterns.swift

@@ -332,6 +332,4 @@ case (_?)?: break // expected-warning {{case is already handled by previous patt
 let (responseObject: Int?) = op1
 // expected-error @-1 {{expected ',' separator}} {{25-25=,}}
 // expected-error @-2 {{expected pattern}}
-// expected-error @-3 {{cannot convert value of type 'Int?' to specified type '(responseObject: _)'}}
-
-
+// expected-error @-3 {{expression type 'Int?' is ambiguous without more context}}