[SR-14993] Missed warning for redundant .some(_) case in the presence of implicit wrapping

[typesanitizer]

Previous ID	SR-14993
Radar	rdar://problem/81357517
Original Reporter	@typesanitizer
Type	Bug

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: f95d824e2da4264fbbf4de7621741d1e

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.

[typesanitizer]

@swift-ci create

[CodaFi]

We could start warning when the unknown default isn't required. Should be an easy fix.