Compiler fails to warn about certain unreachable match arms containing exclusive ranges #43267
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
F-exclusive_range_pattern
`#![feature(exclusive_range_pattern)]`
requires-nightly
This issue requires a nightly compiler in some way.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
In each case, the second arm of the match is unreachable, but the compiler fails to generate a warning.
This is related to #43253, but more tricky to resolve. There are problems with all of the first three match arms of the following function from
librustc_const_eval/_match.rs
:The problem with the first two arms is resolved by #43266. The third arm cannot be fixed in a similar fashion. Essentially, this function tries to work out whether the range represented by
ctor
fits entirely within the range determined by the function parameters, and does so using the results of comparisons between the endpoints of the two ranges.This is not sufficient information to determine if an exclusive range fits within an inclusive range. In particular, for ranges of integers:
1..11
fits entirely within1...10
1..12
does not fit entirely within1...10
This is despite the results of comparisons between the range endpoints are the same in each case.
The fix here will probably need to treat discrete ranges (e.g. of integers) differently from continuous ranges (e.g. of floating point numbers - yes, everything is discrete to a computer, but that's not how people think when actually using floating point numbers!)
The text was updated successfully, but these errors were encountered: