[CodeCompletion][Sema] Don't guess whether a solution will be applied to the AST based on solutions formed for code completion.

When solving for code completion, we ignore missing arguments after the one
containing the code completion location, don't favor overloads with a number of
params matching the number of arguments in a call and so on. Because of this,
we can't assume multiple solutions being formed when solving for code completion
means there won't be a single best solution formed when solving for regular
type-checking.

Resolves rdar://problem/72362275

Author: Nathan Hawes

lib/Sema/TypeCheckCodeCompletion.cpp

@@ -821,20 +821,6 @@ static void filterSolutions(SolutionApplicationTarget &target,
   });
 }
 
-/// When solving for code completion we still consider solutions with holes as
-/// valid. Regular type-checking does not. This is intended to return true only
-/// if regular type-checking would consider this solution viable.
-static bool isViableForReTypeCheck(const Solution &S) {
-  if (llvm::any_of(S.Fixes, [&](const ConstraintFix *CF) {
-    return !CF->isWarning();
-  }))
-    return false;
-  using Binding = std::pair<swift::TypeVariableType *, swift::Type>;
-  return llvm::none_of(S.typeBindings, [&](const Binding& binding) {
-    return binding.second->hasHole();
-  });
-}
-
 bool TypeChecker::typeCheckForCodeCompletion(
     SolutionApplicationTarget &target, bool needsPrecheck,
     llvm::function_ref<void(const Solution &)> callback) {
@@ -931,15 +917,14 @@ bool TypeChecker::typeCheckForCodeCompletion(
       }
 
       // At this point we know the code completion expression wasn't checked
-      // with the closure's surrounding context. If a single valid solution
-      // was formed we can wait until the body of the closure is type-checked
-      // and gather completions then.
-      if (solutions.size() == 1 && isViableForReTypeCheck(solution))
-        return CompletionResult::NotApplicable;
-
-      // Otherwise, it's unlikely the body will ever be type-checked, so fall
-      // back to manually checking a sub-expression within the closure body.
-      return CompletionResult::Fallback;
+      // with the closure's surrounding context, so can defer to regular type-
+      // checking for the current call to typeCheckExpression. If that succeeds
+      // we will get a second call to typeCheckExpression for the body of the
+      // closure later and can gather completions then. If it doesn't we rely
+      // on the fallback typechecking in the subclasses of
+      // TypeCheckCompletionCallback that considers in isolation a
+      // sub-expression of the closure that contains the completion location.
+      return CompletionResult::NotApplicable;
     }
 
     llvm::for_each(solutions, callback);

test/IDE/complete_ambiguous.swift

@@ -45,6 +45,8 @@
 // RUN: %swift-ide-test -code-completion  -source-filename %s -code-completion-token=MULTICLOSURE_FUNCBUILDER | %FileCheck %s --check-prefix=POINT_MEMBER
 // RUN: %swift-ide-test -code-completion  -source-filename %s -code-completion-token=MULTICLOSURE_FUNCBUILDER_ERROR | %FileCheck %s --check-prefix=POINT_MEMBER
 // RUN: %swift-ide-test -code-completion  -source-filename %s -code-completion-token=MULTICLOSURE_FUNCBUILDER_FIXME | %FileCheck %s --check-prefix=NORESULTS
+// RUN: %swift-ide-test -code-completion  -source-filename %s -code-completion-token=REGULAR_MULTICLOSURE_APPLIED | %FileCheck %s --check-prefix=POINT_MEMBER
+
 
 struct A {
   func doAThings() -> A { return self }
@@ -425,3 +427,14 @@ CreateThings {
     }
     Thing. // ErrorExpr
 }
+
+
+func takesClosureOfPoint(_: (Point)->()) {}
+func overloadedWithDefaulted(_: ()->()) {}
+func overloadedWithDefaulted(_: ()->(), _ defaulted: Int = 10) {}
+
+takesClosureOfPoint { p in
+  overloadedWithDefaulted {
+    if p.#^REGULAR_MULTICLOSURE_APPLIED^# {}
+  }
+}