This is an archive of the discontinued LLVM Phabricator instance.

[analysis] Fix value tracking for pointers to qualified types
ClosedPublic

Authored by vabridgers on Nov 28 2019, 5:50 PM.

Details

Summary

This change fixes part 1 described by Artem in the Bugzilla report 43364. The comparison done was on a canonical, but should have been done on an unqualified type. Without using the unqualified type, the type comparison in this specific case is for "const Type * const" against "Type * const", which for the purposes of static analysis can be done not considering the Type's const qualifier. This is best done using a nonqualified type comparison.
Test cases were added to cover this change.

Diff Detail

Event Timeline

vabridgers created this revision.Nov 28 2019, 5:50 PM
bjope added a subscriber: bjope.Nov 29 2019, 9:23 AM
dkrupp added a subscriber: dkrupp.Dec 4 2019, 7:35 AM
NoQ accepted this revision.Dec 5 2019, 1:42 PM
NoQ edited reviewers, added: NoQ; removed: dergachev.a.
NoQ added a subscriber: NoQ.

Thanks!! This definitely doesn't sort out all the problems of this kind, but that's a strict improvement.

Do you have commit access? Or i could commit for you.

clang/test/Analysis/uninit-val-const-likeness.c
21

I suggest adding // no-warning markers on the lines on which warnings were previously emitted. It doesn't have any physical meaning, just makes it easier to understand what the test is about when you accidentally break it.

NoQ accepted this revision.Dec 11 2019, 12:48 PM

Hmm, it was supposed to get a green tick mark. Let me re-accept.

This revision is now accepted and ready to land.Dec 11 2019, 12:48 PM
This revision was automatically updated to reflect the committed changes.

Great! I have one question though. Will this also work as intended with sugared types? (e.g. typedefs)
I believe this might be one of the main reason why the original author used canonical types in the first place.

NoQ added a comment.Dec 18 2019, 6:02 PM

Will this also work as intended with sugared types? (e.g. typedefs)
I believe this might be one of the main reason why the original author used canonical types in the first place.

Whoops, indeed. Fxd in rGf0ced2ddb44e.