-
Couldn't load subscription status.
- Fork 15k
[clang-tidy] modernize-use-nullptr matches "NULL" in templates #109169
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
Conversation
|
@llvm/pr-subscribers-clang-tools-extra @llvm/pr-subscribers-clang-tidy Author: Thomas Köppe (tkoeppe) ChangesMake modernize-use-nullptr matcher also match "NULL", but not "0", when it appears on a substituted type of a template specialization. Previously, any matches on a substituted type were excluded, but this meant that a situation like the following is not diagnosed: template <typename T>
struct X {
T val;
X() { val = NULL; } // should diagnose
};When the user says Full diff: https://github.com/llvm/llvm-project/pull/109169.diff 2 Files Affected:
diff --git a/clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp b/clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
index 6a003a347badac..b2921690863b84 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseNullptrCheck.cpp
@@ -38,7 +38,9 @@ AST_MATCHER(Type, sugaredNullptrType) {
StatementMatcher makeCastSequenceMatcher(llvm::ArrayRef<StringRef> NameList) {
auto ImplicitCastToNull = implicitCastExpr(
anyOf(hasCastKind(CK_NullToPointer), hasCastKind(CK_NullToMemberPointer)),
- unless(hasImplicitDestinationType(qualType(substTemplateTypeParmType()))),
+ anyOf(hasSourceExpression(gnuNullExpr()),
+ unless(hasImplicitDestinationType(
+ qualType(substTemplateTypeParmType())))),
unless(hasSourceExpression(hasType(sugaredNullptrType()))),
unless(hasImplicitDestinationType(
qualType(matchers::matchesAnyListedTypeName(NameList)))));
diff --git a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-nullptr.cpp b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-nullptr.cpp
index 7bc0925136aa86..1807d6bd56125b 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-nullptr.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-nullptr.cpp
@@ -84,6 +84,14 @@ void test_macro_expansion4() {
#undef MY_NULL
}
+template <typename T> struct pear {
+ T x;
+};
+void test_templated() {
+ pear<int*> p = { NULL };
+ dummy(p.x);
+}
+
#define IS_EQ(x, y) if (x != y) return;
void test_macro_args() {
int i = 0;
|
clang-tools-extra/test/clang-tidy/checkers/modernize/use-nullptr.cpp
Outdated
Show resolved
Hide resolved
6e056a2 to
d8a4676
Compare
|
Please mention changes in Release Notes. |
d8a4676 to
6077d49
Compare
|
Done! |
6077d49 to
2f98433
Compare
2f98433 to
2b86607
Compare
a7ea146 to
d4e208f
Compare
d4e208f to
1149cba
Compare
|
@EugeneZelenko Could you please have another look? |
|
I mostly check documentation and minor code issues. Please wait for at least one of active developers whom I added to reviewers list. |
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.
LGTM
…t not "0", when it appears on a substituted type of a template specialization.
Previously, any matches on a substituted type were excluded, but this meant that a situation like the following is not diagnosed:
```c++
template <typename T>
struct X {
T val;
X() { val = NULL; } // should diagnose
};
```
When the user says `NULL`, we expect that the destination type is always meant to be a pointer type, so this should be converted to `nullptr`. By contrast, we do not propose changing a literal `0` in that case, which appears as initializers of both pointer and integer specializations in reasonable real code. (If `NULL` is used erroneously in such a situation, it should be changed to `0` or `{}`.)
1149cba to
07df4ed
Compare
|
What happens next, do we need more approvals? @EugeneZelenko? |
I think two approvals from active developers are enough. |
Make modernize-use-nullptr matcher also match "NULL", but not "0", when it appears on a substituted type of a template specialization.
Previously, any matches on a substituted type were excluded, but this meant that a situation like the following is not diagnosed:
When the user says
NULL, we expect that the destination type is always meant to be a pointer type, so this should be converted tonullptr. By contrast, we do not propose changing a literal0in that case, which appears as initializers of both pointer and integer specializations in reasonable real code. (IfNULLis used erroneously in such a situation, it should be changed to0or{}.)