[clang] Thread Safety Analysis: Drop call-based alias invalidation (PR #187691)

[Aaron Puchert via cfe-commits]

aaronpuchert wrote:

> I had to revert because it causes Linux kernel build errors (false positives), so I need to take another look.

Could you provide some details? Was a variable being reused for something else?

> In particular, I didn't like that we effectively undid what testPointerAliasEscapeMultiple() was testing (avoid false negatives for this case, which @ziqingluo-90 fixed earlier).

I actually liked it. If we're doing alias analysis, then for all we know, `F` and `Fp` point to the same thing. This call invalidation will work in some examples and in others it will fail, and I don't think we'll ever get everything right. I think we have to keep this limited and predictable.

> And I found real cases in the Linux kernel where there's some reallocation of an object going on that I _do_ want to catch (or suppress explicitly).

We can't catch everything, and especially tracking values or variables is a bit out-of-scope for us.

It might be interesting though it the alias analysis is what causes the false negative, i.e. if there would be a warning without it.

https://github.com/llvm/llvm-project/pull/187691