-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[clang-tidy] Fix readability-container-data-pointer check
#165636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
zeyi2
wants to merge
7
commits into
llvm:main
Choose a base branch
from
zeyi2:readability-container-data-pointer-fix
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+47
−16
Open
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
f29accd
[clang-tidy] Fix `readability-container-data-pointer` check
zeyi2 b7dcb77
add release notes and fix minor issue
zeyi2 76bc6cf
fix docs
zeyi2 f63a789
Add more tests
zeyi2 1c60089
minor fix
zeyi2 4170744
fix format issue
zeyi2 3c551a9
fix `AsIs`
zeyi2 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -35,6 +35,12 @@ template <typename T> | |
| struct enable_if<true, T> { | ||
| typedef T type; | ||
| }; | ||
|
|
||
| template <typename T> | ||
| struct unique_ptr { | ||
| T &operator*() const; | ||
| T *operator->() const; | ||
| }; | ||
| } | ||
|
|
||
| template <typename T> | ||
|
|
@@ -144,3 +150,18 @@ int *r() { | |
| // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer] | ||
| // CHECK-FIXES: return holder.v.data(); | ||
| } | ||
|
|
||
| void s(std::unique_ptr<std::vector<unsigned char>> p) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we add test with templated function and
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi, thanks for reviewing. I've added a new test as requested :) |
||
| f(&(*p)[0]); | ||
| // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer] | ||
| // CHECK-FIXES: f((*p).data()); | ||
| } | ||
|
|
||
| template <typename T> | ||
| void u(std::unique_ptr<T> p) { | ||
| f(&(*p)[0]); | ||
| // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'data' should be used for accessing the data pointer instead of taking the address of the 0-th element [readability-container-data-pointer] | ||
| // CHECK-FIXES: f((*p).data()); | ||
| } | ||
|
|
||
| template void u<std::vector<int>>(std::unique_ptr<std::vector<int>>); | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You moved
TK_AsIsfrom functions-level toaddMatcherwhich essentially is the same.What I suggest is not introducing
TK_AsIsin the first place anywhereUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, I tried to implement the new check without
TK_AsIsand I encountered some difficulties:The former template case
mis a simple "dependent type + subscript" inside a template body. The old matcher can recognize containers by inspecting the primary template declaration. The new test caseuis an "overloaded operator* followed by operator[]", it requires knowing that the dependent result typeTactually has adata()method to safely emit(*p).data().With
TK_IgnoreUnlessSpelledInSource, many nodes remain dependent in uninstantiated template bodies, which makes predicates fail to check whether the type really has.data().To fix this issue, I switched to a syntax‑driven approach that doesn’t rely on type constraints in the matcher (only matches address-of subscript zero) and do all container detection in
check(). But still, resolving "type has a public data()" on a dependent specialization is not reliably possible, so now the fix form (return v.data();)cannot be emitted conservatively.I think it will be hard to proceed without
TK_AsIs, I may need to reimplement a dependency-aware walk from a dependent specialization back to its primary template incheck(), which may introduce more problems.Would you be open to a compromise where we enable
TK_AsIsonly for this check? IMHO it is a more practical and low-risk option.Please forgive any shortcomings in my English. If anything isn’t clear, please let me know. I appreciate all feedback.