Flags uses of const-qualified and reference data members in structs.
Implements rule C.12 of C++ Core Guidelines.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-const-or-ref-data-members.cpp | ||
---|---|---|
26 | Differentiate between lvalue reference and rvalue reference members using these terms instead of "ref" and "refref". E.g.:
(apply to all cases below). | |
41 | ConstAndRefMembers | |
101 | Should we test for array types also? E.g.: template<int N> using Array = int[N]; struct ConstArrayMember { const Array<1> c; }; struct LvalueRefArrayMember { Array<2>& lvr; }; struct ConstRefArrayMember { Array<3> const& clvr; }; struct LvalueRefArrayMember { Array<4>&& rvr; }; | |
122 | Consider expanding with the the non-const lvalue ref case, e.g. TemplatedOk<int> t4{}; TemplateRef<int&> t5{t4.t}; |
Address review comments.
Rebase on latest main.
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidConstOrRefDataMembersCheck.h | ||
---|---|---|
30 | Done. I generated this check via add_new_check.py - should we add this there as well to avoid similar issues in the future (separate commit)? I see some checks implement this function and some others don't, so it's not totally clear to me when is needed. |
Tests and docs have moved to subdirectories by module name.
Please rebase onto HEAD and:
- move test/clang-tidy/checkers/cppcoreguidelines-avoid-const-or-ref-data-members.cpp to test/clang-tidy/checkers/cppcoreguidelines/avoid-const-or-ref-data-members.cpp
- move docs/clang-tidy/checks/cppcoreguidelines-avoid-const-or-ref-data-members.rst to docs/clang-tidy/checks/cppcoreguidelines/avoid-const-or-ref-data-members.rst
- make the target test-clang-extra to validate your tests still pass
- make the target docs-clang-tools-html to validate your documentation links are correct
@LegalizeAdulthood I've addressed your comments, thanks for the clear instructions! One thing I didn't manage to do is build the target docs-clang-tools-html, it says it doesn't exist. I've enabled LLVM_BUILD_DOCS=ON in the CMake call - do you know if I need to enable something else?
PS: also the test-clang-extra doesn't exist, I typically run check-clang-tools-extra.
@LegalizeAdulthood Thanks for the review! I've now rebased and addressed your comments. I've also verify the docs with the command you suggested, I was missing -DLLVM_ENABLE_SPHINX in the cmake command.
@LegalizeAdulthood I've addressed your comments, is there anything else that should be fixed before landing the patch?
- Rebase onto latest main.
- Remove references to std::reference_wrapper as alternative suggestions, as per: https://github.com/isocpp/CppCoreGuidelines/issues/1919
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/avoid-const-or-ref-data-members.cpp | ||
---|---|---|
103–104 ↗ | (On Diff #448323) | I feel like this could potentially confuse users. Maybe we should walk the alias to show where the type was declared to be const/reference. |
136–157 ↗ | (On Diff #448323) | This whole block displeases me. Warning on the instantiation isn't a great idea and could confuse users. |
Great feedback, thanks! I had some ideas on how to go around the issues, looking forward to your thoughts.
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/avoid-const-or-ref-data-members.cpp | ||
---|---|---|
103–104 ↗ | (On Diff #448323) | Sounds reasonable! I see that Clang compiler does not print an "alias stack" in detail, for example here: https://godbolt.org/z/8sqE4fM1v For the sake of consistency and simplicity, would it make sense to print something similar here? Example: "warning: member 'c' of type 'ConstType' (aka 'const int') is const qualified" |
136–157 ↗ | (On Diff #448323) | I agree with the sentiment 100%. Unfortunately it's currently the only way to test this kind of code in clang-tidy AFAIK, see for example other existing checks: I fully agree on needing expansion notes, just like the Clang compiler does. A very similar question about it was recently posted: https://discourse.llvm.org/t/clang-tidy-diagnostics-for-template-code/62909 In that sense I believe it would make sense to try and focus the efforts into implementing a good centralized solution instead of having it duplicated on different checks. Until then, I believe it should be fairly easy to clarify the actual type as proposed in the above comment for aliases. What do you think? |
@njames93 I've updated the patch with extra type information, let me know if you think it's good enough!
LGTM. All comments have been addressed. Any improvements to the diagnostics can be made down the line depending on how users feel about them.
Please add isLanguageVersionSupported.