A unicode scalar initialization now errors about overflow since the Dec. 19 trunk snapshot

[finagolfin]

Description

I can no longer build the swift-experimental-string-processing package on linux x86_64 or Android AArch64:

> ../swift-DEVELOPMENT-SNAPSHOT-2024-12-19-a-fedora39/usr/bin/swift build
--- snip other output ---
swift-experimental-string-processing/Sources/Exercises/Participants/HandWrittenParticipant.swift:63:44: error: integer literal '2045' overflows when stored into 'UInt8'
 61 | 
 62 |   // For testing our framework
 63 |   if forceFailure, lower == Unicode.Scalar(0x07FD) {
    |                                            `- error: integer literal '2045' overflows when stored into 'UInt8'
 64 |     return nil
 65 |   }

Patching that call to force unwrap like so, Unicode.Scalar(0x07FD)!, now gets the compiler to choose the right overload that returns an optional and takes larger values to avoid this issue.

Whether this build issue should be fixed in the compiler or the regex package depends on whether this was a conscious decision to break such code, which I'm guessing is a consequence of @xedin's #63585 that was finally merged last week.

Expected behavior

Builds fine with the prior trunk Dec. 16 snapshot and the latest 6.0 and 6.1 releases

Environment

Swift 6.2 on Linux x86_64 and Android AArch64

[natecook1000]

Standalone reproducer — builds with the 12/16 snapshot, but gives the error above for the 12/19 and later toolchains:

let lower: Unicode.Scalar = "a"
if lower == Unicode.Scalar(0x07FD) {
    print("Y")
} else {
    print("N")
}

[finagolfin]

@xedin, I had built the last Dec. 22 snapshot tag before winter break natively on Android and it was exhibiting this issue, so I reverted your #63585 and rebuilt that compiler and this issue went away. It appears this issue is clearly a consequence of your pull, please advise on how we should approach this problem.

[xedin]

Hello! Sorry I just got back from vacation. I think we should treat this as a regression and fix it in the solver. I took a quick look and it looks like we started preferring a concrete overload of == that takes non-optional Unicode.Scalar as arguments and that force the solver to select a non-failing overload of Unicode.Scalar initializer that takes UInt8. I have a few ideas how to address this and will try to open a PR in the next few days.