-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 should take more care about literal representation #1252
Comments
ghost
assigned marijnh
Dec 2, 2011
This is a less specific form of #974, yes? |
Right. |
flip1995
added a commit
to flip1995/rust
that referenced
this issue
Dec 6, 2020
Add Collapsible match lint changelog: Add collapsible_match lint Closes rust-lang#1252 Closes rust-lang#2521 This lint finds nested `match` or `if let` patterns that can be squashed together. It is designed to be very conservative to only find cases where merging the patterns would most likely reduce cognitive complexity. Example: ```rust match result { Ok(opt) => match opt { Some(x) => x, _ => return, } _ => return, } ``` to ```rust match result { Ok(Some(x)) => x, _ => return, } ``` These criteria must be met for the lint to fire: * The inner match has exactly 2 branches. * Both the outer and inner match have a "wild" branch like `_ => ..`. There is a special case for `None => ..` to also be considered "wild-like". * The contents of the wild branches are identical. * The binding which "links" the matches is never used elsewhere. Thanks to the hir, `if let`'s are easily included with this lint since they are desugared into equivalent `match`'es. I think this would fit into the style category, but I would also understand changing it to pedantic.
bjorn3
added a commit
to bjorn3/rust
that referenced
this issue
Aug 24, 2022
Move test script to y.rs
coastalwhite
pushed a commit
to coastalwhite/rust
that referenced
this issue
Aug 5, 2023
celinval
pushed a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Literals should probably be represented in high-precision, with literal arithmetic evaluated outside of LLVM, and only the result used as an LLVM constant.
Currently
lit_int
is represented by anint
, making-2147483648
(or the 64-bit equivalent) lossy. The machine ints are all represented byint
. Foru32
,i64
, andu64
, this is not enough. Fori32
, the problem mentioned above still comes up.The text was updated successfully, but these errors were encountered: