[QoI] fix diagnosis of non-Optional enum used in optional pattern

[jtbandes]

enum Foo { case Bar }
let maybeFoo = Foo.bar

Previously:

error: enum case 'Some' not found in type 'Foo'
guard let foo = maybeFoo else { fatalError() }
          ^

Now:

error: initializer for conditional binding must have Optional type, not 'Foo'
guard let foo = maybeFoo else { fatalError() }
          ^

Resolves SR-1456.

[jtbandes]

Hmm, there is a strange test case in SILGen/statements.swift where guard let t = a is expected to work when a is a custom optional type:

enum MyOptional<Wrapped> {
  case none
  case some(Wrapped)
}

Is this something we should still support? cc @lattner who originally wrote it

[DougGregor]

That's weird; we don't want to support anything other than the true optional types in if-let/guard-let.

[slavapestov]

Renaming MyOptional to Optional might do the trick.

[jtbandes]

Would removing this be a language change that would need to go through swift-evolution? It seems like a bugfix, but conceivably some people could be using it.

[jtbandes]

I pre-emptively updated the commit to simply remove that test. 🙂
@swift-ci please smoke test

On a related note, how would y'all feel about coercePatternToType() gaining a new argument, a SourceLoc for the initializer expression (if there is one)? I'd love to have this diagnostic point to the initializer rather than the bound variable. I can do that in a separate PR.

[jtbandes]

@swift-ci please test

[DougGregor]

I don't consider this a language change that needs swift-evolution. And, passing a SourceLoc for the initializer seems totally reasonable here. Thanks!

[jtbandes]

@DougGregor OK, thanks! If that qualifies as "LGTM", feel free to merge — GitHub won't let me do it for some reason.

What's the procedure for nominating changes for Swift 3.0? Do I just make another PR against swift-3.0-branch?

[DougGregor]

Merged. You can make a PR against the swift-3.0-branch, given it a 3.0 milestone, and assign to @tkremenek .