Skip to content

Range bound error in match has bad error message when integer literal wraps #68972

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

Closed
Lokathor opened this issue Feb 8, 2020 · 3 comments · Fixed by #106622
Closed

Range bound error in match has bad error message when integer literal wraps #68972

Lokathor opened this issue Feb 8, 2020 · 3 comments · Fixed by #106622
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-patterns Relating to patterns and pattern matching C-bug Category: This is a bug. D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Lokathor
Copy link
Contributor

Lokathor commented Feb 8, 2020

For a match where I'm matching on a u8, I put 251..=256 on accident, and then rather than saying that 256 is out of range for u8, it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range:

error[E0030]: lower range bound must be less than or equal to upper                        
  --> src\lib.rs:86:7
   |
86 |       251..=256 => StarClass::BlueGiant,
   |       ^^^ lower bound larger than upper bound

Clearly this is not a good situation.

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 8, 2020
@hirschenberger
Copy link
Contributor

I'd like to fix this

@rustbot claim

@JohnTitor
Copy link
Member

Triage: I'm going to release assignment due to inactivity.
@hirschenberger If you're still interested in this, feel free to re-claim.
@rustbot release-assignment

@rustbot rustbot removed their assignment Jul 24, 2020
@LeSeulArtichaut LeSeulArtichaut added D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. A-patterns Relating to patterns and pattern matching labels Feb 8, 2021
@estebank
Copy link
Contributor

estebank commented Feb 9, 2021

Explanation on how to solve this in #81903 (comment):

the error is being emitted here

(RangeEnd::Excluded, _) => {
struct_span_err!(
self.tcx.sess,
span,
E0579,
"lower range bound must be less than upper"
)
.emit();
PatKind::Wild
}

You would also need access to the AST to figure out that the issue is an overflow, unless the const value of variant Scalar actually has the right value (255 instead of 0). If it does, it just requires you to see that the start is 0 and the end is the maximally representable integer in the type being used and add a note to the error explaining what is happening. In the former case, you will need to pass along the expressions available here into the fn emitting the error:

hir::PatKind::Range(ref lo_expr, ref hi_expr, end) => {
let (lo_expr, hi_expr) = (lo_expr.as_deref(), hi_expr.as_deref());
let lo_span = lo_expr.map_or(pat.span, |e| e.span);
let lo = lo_expr.map(|e| self.lower_range_expr(e));
let hi = hi_expr.map(|e| self.lower_range_expr(e));
let (lp, hp) = (lo.as_ref().map(|x| &x.0), hi.as_ref().map(|x| &x.0));
let mut kind = match self.normalize_range_pattern_ends(ty, lp, hp) {
Some((lc, hc)) => self.lower_pattern_range(ty, lc, hc, end, lo_span),

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 11, 2023
@bors bors closed this as completed in 52d534e Jan 12, 2023
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 A-patterns Relating to patterns and pattern matching C-bug Category: This is a bug. D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants