[DNM] Fix SILGenPattern fallthrough issues.

[gottesmm]

This PR attempts to first provide vardecls on all CaseStmts and use those to fix the SILGenPattern fallthrough issue.

rdar://problem/47467128

[gottesmm]

@jrose-apple I made the change to just store the VarDecl copies into the CaseStmt. I am still I think running into name binding issues since in the following simple test case, the var decl in the .first, .third case seems to not resolve to the appropriate address only slot. Your thoughts?

enum Either<T> {
case first(T)
case second(T)
case third(T)
}

func main<T : BinaryInteger>(_ v: Either<T>) {
  switch v {
  case .first(let count), .third(let count):
    print(count)
  case .second(let count):
    print(count)
  }
}

main(Either.first(10))

[gottesmm]

From reading the AST, I think the problem is that in the body of the case stmts we are generating declref_expr instead of unresolved_declref_expr when parsing.

[jrose-apple]

I'm not sure how to fix that. The parser does do some eager decl binding in parseExprIdentifier, and it ought to be safe to turn that off within cases (it's already turned off sometimes, as you can see), but that's suddenly a bigger change than this was originally. You should probably ask Doug and Rintaro if you want to go down that route.

[gottesmm]

Maybe the thing to do is to create the vardecls in the parser. Then we can keep the optimizations.

[jrose-apple]

That could work too, haven't thought through how difficult it would be. It'll make copying the types over trickier, though.

[gottesmm]

@DougGregor @rintaro

[gottesmm]

@jrose-apple I don't think it will be an issue since we start by processing the cases. I can just take the first case label there and use that to seed the case stmt.

[gottesmm]

and then I can change the short cut in the body to reference the case stmts var decls directly. So we still have the optimization.

[gottesmm]

I have gone down the path I mentioned in this PR in #23056. Closing!