[PATCH] D50619: [clang-tidy] Handle unresolved expressions in ExprMutationAnalyzer

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

I see, thank you for the clarification :)

Am 15.08.2018 um 19:25 schrieb Shuai Wang via Phabricator:

> shuaiwang added inline comments.
> 
> ================
>  Comment at: unittests/clang-tidy/ExprMutationAnalyzerTest.cpp:410
>  +      match(withEnclosingCompound(declRefTo("y")), AST->getASTContext());
>  +  EXPECT_THAT(mutatedBy(ResultsY, AST.get()), ElementsAre("y"));
>  +}
> 
>  ----------------
> 
> JonasToth wrote:
> 
>> Out of curiosity: Why is the result with `y` different from the result for `x`? Both time `x` is mutated and `g()` mutates them.
> 
> This is ultimately caused by not handling pointers yet.
>  As soon as the address of an object is taken we assume the object is mutated.
>  e.g.
> 
>   void f(const int*);
>   void g() {
>     int x;
>     f(&x); // <-- address of x taken, assume mutation
>     int y[10];
>     f(y); // <-- address of y taken, assume mutation
>   }
> 
> 
> And in all such cases the "mutated by" expression is the expression that takes the address.
> 
> So back in this case, `g(x)` mutates `x` because we're assuming `g` mutates its argument through non-const reference. Note that the declared `g` might not be the one actually being called because of overload resolution, there could be another `void g(char(&)[8])`
>  While for `g(y)` we know it's calling the `void g(char*)` so there's an array to pointer decay, and the decay is the point we assumed mutation not the function call.
> 
> Repository:
> 
>   rCTE Clang Tools Extra
> 
> https://reviews.llvm.org/D50619


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D50619