[clang-tidy]: Use correct term for user-provided constructor #96617
Conversation
First of all, fix a confusion in the documentation for pro-type-member-init which used the wrong term for a user-provided constructor. (In the corresponding comment in ProTypeMemberInitCheck.h, which was added in the same commit that added this documentation, we already use the correct term). Second, also fix a comment in the corresponding test that had the same mistake. https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5: > A function is user-provided if it is user-declared and not explicitly > defaulted or deleted on its first declaration. ("user-defined constructor" is not a thing in the standard)
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write If you have received no comments on your PR for a week, you can request a review If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
@llvm/pr-subscribers-clang-tools-extra @llvm/pr-subscribers-clang-tidy Author: Anders Schau Knatten (knatten) ChangesFirst of all, fix a confusion in the documentation for pro-type-member-init which used the wrong term for a user-provided constructor. (In the corresponding comment in ProTypeMemberInitCheck.h, which was added in the same commit that added this documentation, we already use the correct term). Second, also fix a comment in the corresponding test that had the same mistake. https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5: > A function is user-provided if it is user-declared and not explicitly ("user-defined constructor" is not a thing in the standard) Full diff: https://github.com/llvm/llvm-project/pull/96617.diff 2 Files Affected:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
index ae55bf7bd7c86..97af01a895e1c 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
@@ -3,7 +3,7 @@
cppcoreguidelines-pro-type-member-init
======================================
-The check flags user-defined constructor definitions that do not
+The check flags user-provided constructor definitions that do not
initialize all fields that would be left in an undefined state by
default construction, e.g. builtins, pointers and record types without
user-provided default constructors containing at least one such
diff --git a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
index eaa73b906ce09..d999b84cae03e 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
@@ -243,7 +243,7 @@ struct PositiveUninitializedBaseOrdering : public NegativeAggregateType,
};
// We shouldn't need to initialize anything because PositiveUninitializedBase
-// has a user-defined constructor.
+// has a user-provided constructor.
struct NegativeUninitializedBase : public PositiveUninitializedBase {
NegativeUninitializedBase() {}
};
|
|
@knatten Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested Please check whether problems have been caused by your change specifically, as How to do this, and the rest of the post-merge process, is covered in detail here. If your change does cause a problem, it may be reverted, or you can revert it yourself. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! |
) First of all, fix a confusion in the documentation for pro-type-member-init which used the wrong term for a user-provided constructor. (In the corresponding comment in ProTypeMemberInitCheck.h, which was added in the same commit that added this documentation, we already use the correct term). Second, also fix a comment in the corresponding test that had the same mistake. https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5: > A function is user-provided if it is user-declared and not explicitly > defaulted or deleted on its first declaration. ("user-defined constructor" is not a thing in the standard)
) First of all, fix a confusion in the documentation for pro-type-member-init which used the wrong term for a user-provided constructor. (In the corresponding comment in ProTypeMemberInitCheck.h, which was added in the same commit that added this documentation, we already use the correct term). Second, also fix a comment in the corresponding test that had the same mistake. https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5: > A function is user-provided if it is user-declared and not explicitly > defaulted or deleted on its first declaration. ("user-defined constructor" is not a thing in the standard)
First of all, fix a confusion in the documentation for pro-type-member-init which used the wrong term for a user-provided constructor. (In the corresponding comment in ProTypeMemberInitCheck.h, which was added in the same commit that added this documentation, we already use the correct term).
Second, also fix a comment in the corresponding test that had the same mistake.
https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5:
("user-defined constructor" is not a thing in the standard)