Description
#![feature(exclusive_range_pattern)]
fn main() {
match 10 {
1...10 => {},
1..10 => {},
_ => {},
};
match 10 {
1...10 => {},
1..11 => {},
_ => {},
};
}
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:
fn range_covered_by_constructor(tcx: TyCtxt, span: Span,
ctor: &Constructor,
from: &ConstVal, to: &ConstVal,
end: RangeEnd) {
...
}
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..11fits entirely within1...101..12does 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!)