Rust: Diagnose unused variable false positives

[geoffw0]

We've seen a lot of false positive results in the wild for the new rust/unused-variable query. I've identified common three patterns, which are tested here:

• the variable is used, but in a macro invocation (we already knew about this issue).
• the variable is introduced on the left side of a pattern, but the accesses that follow are not correctly identified (they are VariableAccessCand, but not VariableAccess).
• the variable is a pattern match on None (I didn't manage to reproduce this issue with any other enum values).

@hvitved do you think any of these have quick fixes I can implement here? Or should I write up issues for them?

[aibaars]

The pattern match on None problem is likely the same problem we ran into on CI where None nodes were sometimes considered PathPat and sometimes IdentPat . I suspect that the problem also applies to other enum values without arguments that are referred to without qualifier. I think this is pretty rare except for the Option type though. Most code uses the EnumType::Constant notation instead of just Constant.

[aibaars]

My work on macro expansion should fix the problem with variables "used" in macro invocations.

[aibaars]

@geoffw0 Could you include some code snippets as examples (aka test cases) in this issue?

[hvitved]

Fix for the while let case here: geoffw0#5

[geoffw0]

My work on macro expansion should fix the problem with variables "used" in macro invocations.

That's great. Though the volume of FPs is breaking the DCA job, so I will probably have to implement a workaround until then.

Could you include some code snippets as examples (aka test cases) in this issue?

Already here. :)

[geoffw0]

I've just added a commit that restricts this query to working in files called main.rs. Obviously this is a temporary and severe restriction, but it should get the DCA job working (it will still show at least a few hundred results!) and does not affect the test. I'll create an issue shortly to track repairing this query.