This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Make `readability-container-data-pointer` more robust
ClosedPublic

Authored by fwolff on Nov 14 2021, 2:18 PM.

Details

Summary

Fixes PR#52245. I've also added a few test cases beyond PR#52245 that would also fail with the current implementation, which is quite brittle in many respects (e.g. it uses the hasDescendant() matcher to find the container that is being accessed, which is very easy to trick, as in the example in PR#52245).

I have not been able to reproduce the second issue mentioned in PR#52245 (namely that using the data() member function is suggested even for containers that don't have it), but I've added a test case for it to be sure.

Diff Detail

Event Timeline

fwolff created this revision.Nov 14 2021, 2:18 PM
fwolff requested review of this revision.Nov 14 2021, 2:18 PM
fwolff updated this revision to Diff 387132.Nov 14 2021, 2:22 PM
fwolff updated this revision to Diff 387133.Nov 14 2021, 2:26 PM
whisperity added inline comments.
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
20–23

Perhaps we could use constexpr llvm::StringLiteral?

fwolff updated this revision to Diff 387384.Nov 15 2021, 1:30 PM
fwolff marked an inline comment as done.
fwolff added inline comments.
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
20–23

Fixed.

compnerd added inline comments.Dec 4 2021, 11:46 AM
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
22

Would you mind using addr-of-container-expr and renaming this to AddrOfContainerExprName?

77

Nice, I do like this, it is quite a bit more succinct. One thing that is a bit less clear to me is that the previous expression was a bit more restrictive in the parameter types to certain expressions, is there a reason that you don't expect that to matter much in practice? If a malformed input is provided, we could now match certain things that we didn't previously, or am I not matching up the conditions carefully enough?

84

The diff shows up odd here, is there a hard tab or is that just the rendering?

fwolff updated this revision to Diff 391869.Dec 4 2021, 12:36 PM
fwolff marked an inline comment as done.
fwolff marked 3 inline comments as done.Dec 4 2021, 12:46 PM
fwolff added inline comments.
clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
77

I have indeed changed things slightly to make everything more consistent. For instance, calling &vp->operator[](0) currently does not yield a warning (Godbolt link), but &v.operator[](0) does, because the old check allowed a pointer to a container for a cxxOperatorCallExpr() (line 62 on the left) but not for cxxMemberCallExpr(). I think this was simply an oversight because the check was written in such a redundant way; my version covers both.

So yes, I have made some checks a bit less restrictive, but I think that's an improvement. Or which cases were you thinking of exactly?

84

I think this is Phabricator's way of saying that the only thing that was changed in this line is the indentation. I haven't used any tabs.

fwolff updated this revision to Diff 391871.Dec 4 2021, 12:46 PM
fwolff marked 2 inline comments as done.

Mostly just nits from me. At a high level, I think this is good, but if someone else wanted to double-check the changes to the matcher statements themselves, that'd be good.

clang-tools-extra/clang-tidy/readability/ContainerDataPointerCheck.cpp
81–105

Might as well use the constructor rather than assignment operator here.

86–87
94

Drop top-level const and spell out the type explicitly.

fwolff marked 3 inline comments as done.Jan 17 2022, 5:09 PM
fwolff updated this revision to Diff 400680.Jan 17 2022, 5:11 PM

Fixed the nits. Thanks for the review @aaron.ballman!

This revision is now accepted and ready to land.Jan 18 2022, 9:56 AM