Those are considered unsafe and should be replaced with simple pointers or
full copies. It recognizes both std::string and ::string.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
clang-tidy/google/CMakeLists.txt | ||
---|---|---|
8 ↗ | (On Diff #11454) | I'd probably call this StringReferenceMemberCheck, but I don't have a strong objection against this name. |
clang-tidy/google/GoogleTidyModule.cpp | ||
35 ↗ | (On Diff #11454) | Where does "runtime" come from? Does that make sense? |
clang-tidy/google/MemberStringReferencesCheck.h | ||
22 ↗ | (On Diff #11454) | Just for my benefit, why are non-const string reference members ok? |
clang-tidy/google/CMakeLists.txt | ||
---|---|---|
8 ↗ | (On Diff #11454) | Less backwards that suggestion is, rename the file I will. |
clang-tidy/google/GoogleTidyModule.cpp | ||
35 ↗ | (On Diff #11454) | We inherited the categories from cpplint.py and I've been following the existing style. I think it makes sense to have a direct mapping from cpplint categories to tidy checks. |
clang-tidy/google/MemberStringReferencesCheck.h | ||
22 ↗ | (On Diff #11454) | The rationale is that you can initialize the following class with a const char *, creating a string temporary and leave a dangling reference. This behavior won't come up with non-const refs. struct S { S(const string &S) : Str(S) {} const string &Str; }; I'll add that info to the checker description comment. |
clang-tidy/google/GoogleTidyModule.cpp | ||
---|---|---|
35 ↗ | (On Diff #11454) | Right. Having references to cpplint.py in some form is valueable, as we could then use the same check identifiers to support targeted NOLINT suppressions already present in the code. The categories ("runtime", "readability", "build", "compatibility" etc.) used in cpplint.py make some sense: they usually reflect which aspects of the code quality the check addresses. In this case "runtime" means that patterns detected by this check may lead to runtime errors (as opposed to just readability issues or compatibility problems). |
clang-tidy/google/MemberStringReferencesCheck.cpp | ||
28 ↗ | (On Diff #11454) | Did you mean "in template instantiations"? We don't (and shouldn't) ignore members in template declarations, if the type is not dependent on template arguments. |