BurtonQin / lockbud

Statically detect memory, concurrency bugs and possible panic locations for Rust.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Integration in Clippy ?

Urgau opened this issue · comments

commented

Great work, I'm wondering if it could be directly integrated into clippy.

Do you think it would be possible ?
If yes, does it sound reasonable to have it as a general mechanism, for example having #[clippy::forbid_call(self, ::crate::module::my_fn)] at the function definition ?

It's hard because lockbud works on MIR while clippy on HIR. lockbud triggers a cargo build underneath and I do not think clippy should go so deep.
But I do believe that adding warning lints for the following cases may help:

// locks called in conditionals of `match` or `if let`
match *a.read().data {
   Some(_) => { ... }
    _ => handle(*a.read().data2),
}

and

handle(a.read().data, a.read().data2);

and

struct Foo {
   data: RwLock<i32>
}
// may deadlock when a and b point to the same Foo.
fn cmp(a: &Foo, b: &Foo) -> bool {
   a.data.read() == b.data.read()
}

Recursive read locks does not mean recursive functions, instead, it means that a lock is called twice in the same thread, and the first one is not unlocked when the second one is called.

Since clippy works on a higher level than lockbud, it lacks some low-level info to detect deadlock bugs. So I think it's infeasible to integrate lockbud into clippy.
Basically, clippy checks code patterns on HIR (like a typed AST). We have found some interesting deadlock code patterns that may be suitable for clippy lints, as listed above.

commented

Fair points. I wonder if clippy maintainers would be open to having lints that work on MIR, maybe within a separate lint group. But this is outside of the scope of my question.

Feel free to close the issue or leave it open for a other patterns that could be integrated.