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

Integer hex literals should perhaps not consider signededness #10713

Closed
alexcrichton opened this issue Nov 29, 2013 · 2 comments
Closed

Integer hex literals should perhaps not consider signededness #10713

alexcrichton opened this issue Nov 29, 2013 · 2 comments

Comments

@alexcrichton
Copy link
Member

I would not expect this code to produce a warning:

fn main() {
    let a: i8 = 0x20;
    assert!(a == 0xff);
}

Although the following warnings are printed

foo.rs:3:12: 3:21 warning: comparison is useless due to type limits, #[warn(type_limits)] on by default
foo.rs:3     assert!(a == 0xff);
                     ^~~~~~~~~
<std-macros>:36:4: 52:5 note: in expansion of assert!
foo.rs:3:4: 3:23 note: expansion site
foo.rs:3:17: 3:21 warning: literal out of range for its type, #[warn(type_overflow)] on by default
foo.rs:3     assert!(a == 0xff);
                          ^~~~
<std-macros>:36:4: 52:5 note: in expansion of assert!
foo.rs:3:4: 3:23 note: expansion site
@lilyball
Copy link
Contributor

lilyball commented Dec 1, 2013

Why shouldn't that produce a warning? Are hex literals somehow magic? I would expect to have to say either assert!(a == 0xffu8 as i8) or assert!(a as u8 == 0xff).

@alexcrichton
Copy link
Member Author

Closing, general opinion is opposite of mine, I think I'm just special in this regard.

flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2023
flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2023
…rted_modules, r=Alexendoo

Fix `items_after_test_module`: Ignore imported modules

Fixes rust-lang#10713. It does a little bit of dark magic, but intention is what really counts.
changelog:[`items_after_test_module`]: Ignore imported modules (`mod foo;`) with no body.
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
`items_after_test_module`: Ignore in-proc-macros items

The library `test-case` is having some problems with this lint, ignoring proc macros should fix it.
Related to rust-lang#10713 and frondeus/test-case#122

(Couldn't add test cases for this exact situation without importing the library, but I think the fix is simple enough that we can be pretty sure there won't be any problems :) )

changelog:[`items_after_test_module`]: Ignore items in procedural macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants