Improve error recovery for && in stmt-condition when followed by

let/var/case.  Thanks to Radek Pietruszewski for noticing this!

Author: lattner

lib/Parse/ParseExpr.cpp

@@ -230,13 +230,16 @@ ParserResult<Expr> Parser::parseExprSequence(Diag<> Message,
       if (!GreaterThanIsOperator && startsWithGreater(Tok))
         goto done;
 
-      // If this is an "&& #available()" expression, then don't eat it.
-      // #available() is not a general expression, and && is an infix operator,
+      // If this is an "&& #available()" expression (or related things that
+      // show up in a stmt-condition production), then don't eat it.
+      //
+      // These are not general expressions, and && is an infix operator,
       // so the code is invalid.  We get better recovery if we bail out from
       // this, because then we can produce a fixit to rewrite the && into a ,
       // if we're in a stmt-condition.
       if (Tok.getText() == "&&" &&
-          peekToken().is(tok::pound_available))
+          peekToken().isAny(tok::pound_available,
+                            tok::kw_let, tok::kw_var, tok::kw_case))
         goto done;
 
       // Parse the operator.

test/stmt/statements.swift

@@ -464,6 +464,9 @@ func f21080671() {
 func f(x : Int, y : Int) {
   if x == y && #available(iOS 9, *) {}  // expected-error {{expected ',' joining parts of a multi-clause condition}} {{13-15=,}}
   if #available(iOS 9, *) && x == y {}  // expected-error {{expected ',' joining parts of a multi-clause condition}} {{27-29=,}}
+
+  // https://twitter.com/radexp/status/694790631881883648
+  if x == y && let _ = Optional(y) {}  // expected-error {{expected ',' joining parts of a multi-clause condition}} {{13-15=,}}
 }