[PATCH] D50619: [clang-tidy] Handle unresolved expressions in ExprMutationAnalyzer
Jonas Toth via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Aug 15 01:01:25 PDT 2018
JonasToth added inline comments.
================
Comment at: unittests/clang-tidy/ExprMutationAnalyzerTest.cpp:117
+TEST(ExprMutationAnalyzerTest, AssumedNonConstMemberFunc) {
+ auto AST = tooling::buildASTFromCode(
----------------
I think you could add another test with `X<T> x` (if you don't have it already and I overlooked them)
================
Comment at: unittests/clang-tidy/ExprMutationAnalyzerTest.cpp:309
+TEST(ExprMutationAnalyzerTest, CallUnresolved) {
+ auto AST =
----------------
I think we are missing tests for non-type template paramters (`template <size_t N>`). They should behave the same. But the following case would not be a mutation:
```
void non_mutating(const char* Array, int size) { /* Foo */ }
template <int N>
struct ArrayLike {
char* data[N]; // Initialized to something
void SomeFunction() {
non_mutating(data, N);
}
};
```
The difference between the 'normal' and non-type templates would be, that `N` is not mutatable at all and the semantics is clear (builtin integer-like type).
If the current implementation would not figure that out, you can just add a test for it and assume a mutation. Handling non-type templates later is absolutly ok.
================
Comment at: unittests/clang-tidy/ExprMutationAnalyzerTest.cpp:410
+ match(withEnclosingCompound(declRefTo("y")), AST->getASTContext());
+ EXPECT_THAT(mutatedBy(ResultsY, AST.get()), ElementsAre("y"));
+}
----------------
Out of curiosity: Why is the result with `y` different from the result for `x`? Both time `x` is mutated and `g()` mutates them.
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D50619
More information about the cfe-commits
mailing list