[CS] Better diagnose inout argument in tuple construction

Previously we relied on `TupleTypeElt::getType`
returning an `InOutType` to fail the tuple type
matching logic. Instead, add logic to reject any
inout arguments up-front with a more specific
diagnostic.

Also, while we're here, strip the `_const`
parameter flag, as it's not something that needs
to be considered for tuple construction.

Author: hamishknight

lib/Sema/CSSimplify.cpp

@@ -6983,10 +6983,33 @@ ConstraintSystem::simplifyConstructionConstraint(
         fnType = contextualType;
       }
     }
+    SmallVector<AnyFunctionType::Param, 4> args;
+    for (auto idx : indices(fnType->getParams())) {
+      auto &arg = fnType->getParams()[idx];
+
+      // We can disregard '_const', it's not applicable for tuple construction.
+      auto flags = arg.getParameterFlags().withCompileTimeConst(false);
+
+      // We cannot handle inout for tuple construction.
+      if (flags.isInOut()) {
+        if (!shouldAttemptFixes())
+          return SolutionKind::Error;
+
+        auto *argLoc = getConstraintLocator(locator, {
+          LocatorPathElt::ApplyArgument(),
+          LocatorPathElt::ApplyArgToParam(idx, idx, ParameterTypeFlags())
+        });
+        auto argTy = arg.getParameterType();
+        if (recordFix(RemoveAddressOf::create(*this, argTy, argTy, argLoc)))
+          return SolutionKind::Error;
+
+        flags = flags.withInOut(false);
+      }
+      args.push_back(arg.withFlags(flags));
+    }
 
     // Tuple construction is simply tuple conversion.
-    Type argType = AnyFunctionType::composeTuple(getASTContext(),
-                                                 fnType->getParams());
+    Type argType = AnyFunctionType::composeTuple(getASTContext(), args);
     Type resultType = fnType->getResult();
 
     ConstraintLocatorBuilder builder(locator);

lib/Sema/ConstraintSystem.cpp

@@ -5608,6 +5608,13 @@ Solution::getFunctionArgApplyInfo(ConstraintLocator *locator) const {
     if (simplifyType(rawFnType)->is<UnresolvedType>())
       return None;
 
+    // A tuple construction is spelled in the AST as a function call, but
+    // is really more like a tuple conversion.
+    if (auto metaTy = simplifyType(rawFnType)->getAs<MetatypeType>()) {
+      if (metaTy->getInstanceType()->is<TupleType>())
+        return None;
+    }
+
     assert(!shouldHaveDirectCalleeOverload(call) &&
              "Should we have resolved a callee for this?");
   }

test/Constraints/diagnostics.swift

@@ -573,7 +573,16 @@ func r22263468(_ a : String?) {
   // TODO(diagnostics): This is a regression from diagnosing missing optional unwrap for `a`, we have to
   // re-think the way errors in tuple elements are detected because it's currently impossible to detect
   // exactly what went wrong here and aggregate fixes for different elements at the same time.
-  _ = MyTuple(42, a) // expected-error {{tuple type '(_const Int, String?)' is not convertible to tuple type 'MyTuple' (aka '(Int, String)')}}
+  _ = MyTuple(42, a) // expected-error {{tuple type '(Int, String?)' is not convertible to tuple type 'MyTuple' (aka '(Int, String)')}}
+}
+
+func testTupleConstructionInOutArg() {
+  typealias II = (Int, Int)
+
+  var i = 0
+  _ = (Int, Int)(&i, 0) // expected-error {{'&' may only be used to pass an argument to inout parameter}}
+  _ = II(&i, 0) // expected-error {{'&' may only be used to pass an argument to inout parameter}}
+  _ = II(&i, &i) // expected-error 2{{'&' may only be used to pass an argument to inout parameter}}
 }
 
 // rdar://71829040 - "ambiguous without more context" error for tuple type mismatch.