In D54399#1391975, @lebedev.ri wrote:

In D54399#1391935, @shuaiwang wrote:

Hi @rsmith what do you think of just get this in since Eric is not responding? Or do you think I should run certain test to verify?

I'm having a déjà vu.
Wasn't there already an attempt to have EMA in clang proper,
and it was scrapped with reasoning along the lines of "it is slow by design"?
If yes, what changed? (one might expect that to be in the description..)

Hi @rsmith what do you think of just get this in since Eric is not responding? Or do you think I should run certain test to verify?

Friendly ping @EricWF

In D54399#1296317, @dblaikie wrote:

Could you fix the modulemap (might amount to reverting the change Eric made in r342827? or maybe it's more involved than that) & validate that the modules build is working with this change (probably undo Eric's change, validate that you see the breakage that Eric was trying to fix, then apply your change & see if it clears up as well)?

Resolved review comments.

Addressed review comments.

Added test case place holder for cases that should be supported in later patches.

Addresses review comments.

In D52219#1238423, @JonasToth wrote:

Do you think it would be possible to the analysis for >const?< int ***-cases? (recursively checking through the pointer levels)

I think that should be possible, will do after single-layer pointee analysis is done. I believe we can build multi-layer analysis based on much of the single-layer analysis.

[WIP] Addressed some of review comments.

Rebase

In rCTE342403#288286, @JonasToth wrote:

@shuaiwang This patch introduces test failures for std::move not considered as a mutation.
Adding move operations to Mutable did not change that. Could you take a look at it? What happens if Move operations are defaulted, does the EMA analyze still correct?

Added test case with copy-ctor & assignment operator taking value as param.

Addressed review comment.

Added more test cases around std::move

@lebedev.ri could you help test whether this fully resolves PR38891? Thanks!

In D52008#1234828, @JonasToth wrote:

The std::move as cast is a follow up patch?

Yes I'll send a follow up patch.

Addressed review comments.

In D52008#1232923, @lebedev.ri wrote:

Thanks for working on this! I tried, and it appears to not fix the issue at hand.

struct C1 {
  C1(const C1* c, int num);
};

int x = 0;
auto y = std::make_unique<C1>(nullptr, x); // <- still considered a mutation?

struct C3 {}; // some class

struct C2 {
  C2(const int* whatever, int n, C3 zz);
};

int x = 0;
std::vector<C2> v;
v.emplace_back(nullptr, x, {}); // <- still considered a mutation?

And so on. These are hand-reduced, so hopefully you can reproduce?

I've patched D51870 and tried these cases, they work correctly with this change plus the change making std::move & std::forward considered casts. I also tested

struct D {
  D(int&);
};
void h() {
  std::vector<D> v;
  for (int i = 0; i < 10; ++i) {
    v.emplace_back(i);
  }
}

and that's also correctly considered as mutation at emplace_back

More test cases addressing review comments

Just some quick comments, I'll take a deeper look into other comments later.

More test cases:

• Mutating pointers
• Const values

In D50953#1230138, @JonasToth wrote:

In D50953#1230003, @shuaiwang wrote:

In D50953#1229287, @JonasToth wrote:

What happens to pointers in a typedef (in the sense of * instead of &)?

I checked around and I believe reference type is the only type we're explicitly matching right now. We'll need to handle carefully when handling pointer types in the future.

We match on pointers as values. So figure this out int * >const< ptr = nullptr.
And the constness transformation is especially intersting for pointer typedefs, because in typedef int * IntPtr; const IntPtr p1; IntPtr const p2; p1 and p2 are different things. It would be nice if you could check, that the value semantic of the pointer is detected through the typedef as well.

more test cases

Yeah let's see what happens in the wild and decide whether we need further actions. In any case I think that deserves a separate diff.
Is there other concerns about this diff?

rebase & add test case

In D50953#1229287, @JonasToth wrote:

What happens to pointers in a typedef (in the sense of * instead of &)?

I checked around and I believe reference type is the only type we're explicitly matching right now. We'll need to handle carefully when handling pointer types in the future.

more test cases.