[TypeChecker] Simplify ExprPattern from Bool literals in Bool? switch

[jameesbrown]

Resolves: swiftlang/swift#61817.

Boolean literals are treated as ExprPatterns when switching over Bool? because they require implicit conversion to Optionals, resulting in them being wrapped in InjectIntoOptionalExprs. Consequently, they do not contribute to exhausting the switch cases.

In this special case, we can instead treat them as true?/false?.

[xedin]

We need equivalent change in CSGen I think and a test-case where a switch is used inside of a closure.

@hamishknight could you please take a look at the changes?

[xedin]

Approved by mistake, meant only to comment.

[jameesbrown]

@xedin Thanks for looking at it. I will investigate a CSGen change and add that test case.

[xedin]

It should be pretty similar to what you already did, look at getTypeForPattern.

[hamishknight]

I'm not actually sure this needs a CSGen change, trySimplifyExprPattern is called for both coercePatternToType and CSApply, and this is something that needs to operate on the type-checked pattern (since ExpressibleByBooleanLiteral means you can't always turn a top-level BooleanLiteralExpr into a BoolPattern). But yes, please add a test case in a closure :)

[jameesbrown]

@hamishknight Thanks! I took your suggestion and rewrote it recursively to handle any level of optionality. I also included the test case inside a closure.

@xedin I explored possible changes in getTypeForPattern, but without already knowing the type of ExprPattern, I couldn’t find a clear solution. It doesn’t seem like a necessary change, though it might be an optimization—potentially solving the constraints earlier?

[hamishknight]

Thanks!

[hamishknight]

@swift-ci please test

[hamishknight]

@swift-ci please test source compatibility

[xedin]

LGTM! I originally thought that this needs to happen earlier.

[jameesbrown]

The source compatibility checks are failing but so far I haven't found a failure that seems related to this change. For example, https://ci.swift.org/job/swift-PR-source-compat-suite-macos/2271/artifact/swift-source-compat-suite/FAIL_SwiftLint_5.0_BuildSwiftPackage.log.

Most seem related to not finding MacOS specific modules, but it looks like that sdk is being properly selected so I'm not sure.

[hamishknight]

Those are the same failures as on main, so yeah they're unrelated

[hamishknight]

@swift-ci please test source compatibility Debug

[hamishknight]

Source compat failures unrelated