Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler fails to warn about certain unreachable match arms containing exclusive ranges #43267

Closed
feadoor opened this issue Jul 16, 2017 · 1 comment
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.

Comments

@feadoor
Copy link
Contributor

feadoor commented Jul 16, 2017

#![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..11 fits entirely within 1...10
  • 1..12 does not fit entirely within 1...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!)

@Mark-Simulacrum Mark-Simulacrum added the A-diagnostics Area: Messages for errors, warnings, and lints label Jul 19, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@Centril Centril added F-exclusive_range_pattern `#![feature(exclusive_range_pattern)]` requires-nightly This issue requires a nightly compiler in some way. labels Dec 12, 2019
@crlf0710 crlf0710 added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 11, 2020
@Nadrieril
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

5 participants