This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Aliasing: Add support for passing the variable into a function by reference.
Needs ReviewPublic

Authored by NoQ on May 3 2021, 3:19 PM.

Details

Summary

This is a fairly basic form of aliasing that as we've noticed in D96215 hasn't been covered yet.

At the same time this patch causes unfortunate false negatives on the regression tests for bugprone-redundant-branch-condition that has a builtin incomplete but slightly more robust solution to the same problem. These false negatives are something that we didn't really have a right to warn at until we've had a more flow-sensitive alias analysis. Like, they're valid warnings but we can't emit them with the analysis that we have without consciously introducing false positives as well. So I think it's a judgement call. I'm definitely in favor of landing it despite the false negatives it introduces but this may go against clang-tidy's philosophy on this issue so I'm open to not landing it.

The patch uses AnyCall in order to cover 5 different AST node kinds for call-like expressions none of which inherit from CallExpr (apart from CallExpr itself).

Diff Detail

Event Timeline

NoQ created this revision.May 3 2021, 3:19 PM
NoQ requested review of this revision.May 3 2021, 3:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 3 2021, 3:19 PM
NoQ updated this revision to Diff 342567.May 3 2021, 3:22 PM

Unforget to git add Objective-{C,C++} tests.

Apart from testing the patch, some of these tests demonstrate that the checker doesn't really work in Objective-C. The problem is that forFunction() doesn't treat Objective-C methods as functions - a similar problem that caused false negatives demonstrated D101787. I hope to address this soon.

+Adam, the original author of bugprone-redundant-branch-condition. Adam, do you have any thoughts regarding the tests regressed by this patch? Are they something we should absolutely keep warning on?

+Adam, the original author of bugprone-redundant-branch-condition. Adam, do you have any thoughts regarding the tests regressed by this patch? Are they something we should absolutely keep warning on?

Actually, this checker did not give any false positives whever I tested it on several open-source projects. I can agree with the one where the function starts another thread which changes its parameter, but the rest, where the local variable is mutated after or in the branch I cannot see any reason to disappear. Can you tell me an example where these are false positives? Why do these warnings disappear?

I agree that all the comments labeled FIXME are ones where I'd expect to see the diagnostic triggered.

NoQ added a comment.May 10 2021, 11:30 AM

I completely agree with that as well, these are 100% true positives, which is why I left them as fixmes. The reason why I think we can't have them is that we don't have an appropriate alias analysis implemented. Namely, we have two analyses, one inside the checker that leaves out false positives like the one in negative_by_val(), the other is the universal/reusable analysis in Utils that i'm patching up that doesn't support happens-before relation.

I believe the right way forward is to unify these analysis by making the analysis in Utils account for happens-before relation. Ideally this means re-implementing it over the CFG which probably isn't even that hard, it's just a simple graph traversal problem. I may look into it in June or so.

NoQ updated this revision to Diff 344283.May 10 2021, 9:04 PM

Rebase on top of D102214 (that patch will probably land sooner than this patch and there are test conflicts).

I completely agree with that as well, these are 100% true positives, which is why I left them as fixmes. The reason why I think we can't have them is that we don't have an appropriate alias analysis implemented. Namely, we have two analyses, one inside the checker that leaves out false positives like the one in negative_by_val(), the other is the universal/reusable analysis in Utils that i'm patching up that doesn't support happens-before relation.

I believe the right way forward is to unify these analysis by making the analysis in Utils account for happens-before relation. Ideally this means re-implementing it over the CFG which probably isn't even that hard, it's just a simple graph traversal problem. I may look into it in June or so.

I think that sounds like the right way forward. Thank you for looking into the unification!