[PATCH] D52219: [analyzer] (1/n) Support pointee mutation analysis in ExprMutationAnalyzer.

Jonas Toth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Sep 22 05:38:11 PDT 2018


JonasToth added inline comments.


================
Comment at: unittests/Analysis/ExprMutationAnalyzerTest.cpp:156
   EXPECT_THAT(mutatedBy(Results, AST.get()), ElementsAre("x.mf()"));
+
+  AST = tooling::buildASTFromCode(
----------------
shuaiwang wrote:
> JonasToth wrote:
> > JonasToth wrote:
> > > I feel that there a multiple tests missing:
> > > 
> > > - multiple levels of pointers `int ***`, `int * const *`
> > > - pointers to references `int &*`
> > > - references to pointers `int *&`
> > > - ensure that having a const pointer does no influence the pointee analysis `int * const p = &i; *p = 42;`
> > > - a class with `operator*` + `operator->` const/non-const and the analysis for pointers to that class
> > > - pointer returned from a function
> > > - non-const reference returned 
> > > ```
> > > int& foo(int *p) {
> > >   return *p;
> > > }
> > > ```
> > > 
> > for the multi-level pointer mutation: it would be enough to test, that the second layer is analyzed properly, and that the `int * >const< *` would be detected.
> Added except for:
> - Anything that requires following a dereference, we need `findPointeeDerefMutation` for that.
> - Pointer to a class with `operator*` + `operator->`, I think those two operators doesn't matter, there's no way to accidentally invoke them from a pointer.
> 
But we want to analyze smart pointers in the future as well, not? It would be good to already prepare that in the testing department.
Or would the nature of `operator*` already make that happen magically?


Repository:
  rC Clang

https://reviews.llvm.org/D52219





More information about the cfe-commits mailing list