Skip to content

Bad Comparison of Upcasted Ints Fix #42 #802

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
wants to merge 17 commits into from

Conversation

cramertj
Copy link
Member

Fix #42.

@cramertj
Copy link
Member Author

While implementing this I noticed that I was duplicating a lot of existing behavior in rustc, especially concerning the function to get bounds for integers. However, that fn is private in the rust lib itself-- is there a standard best practice for handling these cases?

@cramertj
Copy link
Member Author

Hm... anybody know what that failure is? It doesn't happen on my machine.

@mcarton
Copy link
Member

mcarton commented Mar 25, 2016

The error on travis is unrelated and only appears on the last nightly version. I’m looking into it.

@@ -67,6 +67,7 @@ name
[ineffective_bit_mask](https://github.com/Manishearth/rust-clippy/wiki#ineffective_bit_mask) | warn | expressions where a bit mask will be rendered useless by a comparison, e.g. `(x | 1) > 2`
[inline_always](https://github.com/Manishearth/rust-clippy/wiki#inline_always) | warn | `#[inline(always)]` is a bad idea in most cases
[invalid_regex](https://github.com/Manishearth/rust-clippy/wiki#invalid_regex) | deny | finds invalid regular expressions in `Regex::new(_)` invocations
[invalid_upcast_comparisons](https://github.com/Manishearth/rust-clippy/wiki#invalid_upcast_comparisons) | warn | a comparison involving an term's upcasting to be within the range of the other side of the term is always true or false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be “an term”. That‘s a complicated sentence I had to read several times :-°. As a short description, maybe “a comparison involving an upcast which is always true or false” would do.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes-- I struggled with how to phrase it concisely.

@mcarton
Copy link
Member

mcarton commented Mar 26, 2016

Looks good expect for the small nits. I’ll look at the Travis error tomorrow, apparently it’s 1AM already and I have no idea how to fix it 😓

Rel::Le => nlb.0 > norm_rhs_val,
} {
// Expression is always false
cx.span_lint(INVALID_UPCAST_COMPARISONS,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I forgot about that yesterday, don’t use cx.span* but one of our span_*. They add a link to Clippy’s wiki.

@cramertj
Copy link
Member Author

@mcarton Any progress on the Travis error?

@mcarton
Copy link
Member

mcarton commented Mar 27, 2016

It’s been fixed by @Manishearth, but you know have a conflict. You’ll have to rebase with master.

@cramertj
Copy link
Member Author

Done.

Usize(Us32(x)) => FullInt::U(x as u64),
Usize(Us64(x)) |
U64(x) => FullInt::U(x),
Infer(x) => FullInt::U(x as u64),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use the erase_type method to only have two kinds to handle here.

@mcarton
Copy link
Member

mcarton commented Mar 29, 2016

😕

Git beginner? 😛
I’ve no idea how you did that, but the PR should't have any commit(s?) besides yours and it should have no duplicate commits so I don’t know what will happen if we merge that. If you don’t know how to fix that, I’ll do it when merging.

@cramertj
Copy link
Member Author

I had conflicts when I did the rebase, so it made me resolve them partway through the rebase (which I think is where the duplicate commits came from). I just ran git pull --rebase. Is there something I should've done differently?

@cramertj
Copy link
Member Author

cramertj commented Apr 2, 2016

@mcarton Anything else you want fixed?

mcarton added a commit that referenced this pull request Apr 2, 2016
mcarton added a commit that referenced this pull request Apr 2, 2016
@mcarton mcarton mentioned this pull request Apr 2, 2016
mcarton added a commit that referenced this pull request Apr 2, 2016
Bad Comparison of Upcasted Ints
@mcarton
Copy link
Member

mcarton commented Apr 2, 2016

Merged (through #828, it needed to be updated again because of #821) 🎉

@mcarton mcarton closed this Apr 2, 2016
if let Some(nlb) = lhs_bounds {
if let Some(norm_rhs_val) = node_as_const_fullint(cx, rhs) {
if rel == Rel::Eq || rel == Rel::Ne {
if norm_rhs_val < nlb.0 || norm_rhs_val > nlb.0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was also a small mistake here, it should be norm_rhs_val > nlb.1. I’ve noticed that while adding more tests. Tests are good 😄

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I appreciate your help.

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

Successfully merging this pull request may close these issues.

2 participants