[PATCH] D52120: [analyzer] Treat std::{move, forward} as casts in ExprMutationAnalyzer.

Jonas Toth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Sep 15 05:39:09 PDT 2018


JonasToth added a comment.

Thank you very much for the good work from my side as well!



================
Comment at: unittests/Analysis/ExprMutationAnalyzerTest.cpp:387
       match(withEnclosingCompound(declRefTo("x")), AST->getASTContext());
-  EXPECT_THAT(mutatedBy(Results, AST.get()), ElementsAre("std::move(x)"));
+  EXPECT_FALSE(isMutated(Results, AST.get()));
+
----------------
I am thinking about the correctness of the change.

If we have this case:
```
std::string s1 = "Hello World!";
std::string s2 = std::move(s1);
```
`s1` gets mutated, but it looks like it would not be considered as mutation?

On the other hand
```
int i1 = 42;
int i2 = std::move(i1);
```
should resolve in a copy `i1` and therefor not be a mutation.

Could you please add tests demonstrating this difference and the correct diagnostic detection for that.

Potentially interesting:
- Builtin types should be Copy-Only?, builtin arrays as expensive to move types for the completeness please as well
- Types with deleted move operations, should resolve in copy too
- Move-Only types like unique_ptr
- Types with both move and copy constructor (vector-like)
- and something with everything defaulted

These thoughts are just thinking and writing, I just wondered that moving a variable with std::move is not considered as mutation here, even though there are cases were it is actually a mutation.


Repository:
  rC Clang

https://reviews.llvm.org/D52120





More information about the cfe-commits mailing list