Issue Description:

Originally noticed here: https://forums.swift.org/t/odd-inconsistent-compile-warning-for-optional-of-enum/50780/8

enum E {
    case e1
}
func f(_ e: E?) {
    switch e {
    case .e1: ()
    case .none: ()
    default: () // warning: default will never be executed
    }
    switch e {
    case .e1: ()
    case .none: ()
    case .some(_): () // no warning :O
    }
}
 

The .some(_) example should also emit a warning.

If you look at -dump-ast the two patterns are different, the .e1 will be a pattern_optional_some implicit whereas the .some(_) will be a pattern_enum_element type='E?' E?.some .

I don't know for sure, but I have a gut feeling that the problem is due to this dual representation. If that's actually the case, trivially canonicalizing the pattern may not be enough (e.g. we could potentially map one kind of pattern to the other to avoid two representations for the same logical thing) because that could end up regressing diagnostics. Introducing a distinction Pattern vs CanPattern (akin to Type vs CanType) distinction seems a bit overkill for this one thing but it may be the best long-term solution...

Tested with Xcode 13 beta 3.