-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add lint for debug_assert_with_mut_call #4680
Conversation
☔ The latest upstream changes (presumably #4657) made this pull request unmergeable. Please resolve the merge conflicts. |
I think I'm done with this? @flip1995 do you want to see anything else? If not, I would rebase and force push the commits and pretty up the first comment in this thread. Are you okay with that? |
58f32c5
to
0dfeca0
Compare
Rebased and ready to ship 🎉 |
I just got one more test idea: let mut x = 42_usize;
debug_assert!({
foo(&mut x);
x > 10
}); |
That's nasty! Who writes such code ^^ Btw: every block isn't covered yet, e.g. |
the span now doesn't point at the function call, but to the block itself. Meh :/ On the other hand:
This doesn't look like if it's inside the |
I've gone full retard mode now and covered every |
7e638e1
to
c1d2ed1
Compare
This makes sense, when you want to write more complex verification code. Though the simplest example is asserting an enum variant: debug_assert!(if let Variant(_) = expr {
true
} else {
false
});
Uh, now you basically rewritten a struct MutArgVisitor {
mut_arg_found: bool,
}
impl intravisit::Visitor for MutArgVisitor {
fn visit_expr(&mut self, expr: &'_ Expr) {
match &expr.kind {
ExprKind::Call(.., args) | ExprKind::MethodCall(.., args) => {
// check args,
if /* any arg is mutable */ {
self.mut_arg_found = true;
}
}
}
walk_expr(expr);
}
} Just grep the Clippy Codebase for |
@Manishearth can you help me again please? I try to solve the
This is the debug output of |
tbh I feel like it's fine if we don't detect that case. The lint is already quite advanced (and I'm hoping it's not too slow to apply) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usage of the visitor should be more like the one of other visitors in the code base. Also as @Manishearth wrote, you can just leave out the mut pointer case.
If you give the okay fir this PR, I will rebase it again and then it can be merged (finally) 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great now, thanks! Rebase and this is ready to go
This lint will complain when you put a mutable function/method call inside a `debug_assert` macro, because it will not be executed in release mode, therefore it will change the execution flow, which is not wanted.
1d15a9c
to
5572476
Compare
Done. Waiting for travis (which failed the last two times, is there something broken?) |
Unrelated to this PR. Rustup in #4715 |
@bors r=flip1995 |
📌 Commit 5572476 has been approved by |
Add lint for debug_assert_with_mut_call closes #1526 **What does not work:** * detecting a mut call in the format string itself, e.g. `debug_assert!(false, "{}", vec![1].pop())` * detecting `*mut T` usage (pointer) --- changelog: add new lint `debug_assert_with_mut_call`
☀️ Test successful - checks-travis, status-appveyor |
closes #1526
What does not work:
debug_assert!(false, "{}", vec![1].pop())
*mut T
usage (pointer)changelog: add new lint
debug_assert_with_mut_call