[PATCH] D50883: [clang-tidy] Handle unique owning smart pointers in ExprMutationAnalyzer

[Shuai Wang via Phabricator via cfe-commits]

shuaiwang added a comment.

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?

In https://reviews.llvm.org/D50883#1230805, @JonasToth wrote:

> Your point is valid, that the decision of what to analyze should be done
>  outside. My const-correctness check does analyze all versions of the
>  templated function, because it just matches on
>  `functionDecl(compoundStmt())`.
>
> Maybe we just need some experience with real world code. The
>  const-correctness thing is close to finish in its first version. Then we
>  can exercise its results.
>
> Am 11.09.2018 um 18:15 schrieb Shuai Wang via Phabricator:
>
> > I see, it's the conflicting results you're going after :)
> >  Good news is that we actually don't analyze all versions, we only analyze the version (instantiated or not) corresponding to the "scope" stmt passed into the constructor. Semantic-wise I feel this makes sense because if we're given an instantiated version we shouldn't bail out because nothing is type-dependent anymore in the instantiated version.
> >  Also I think conflicts won't happen much in practice, most (all?) checks naturally pass in the uninstantiated version, in order to pass in an instantiated version a check needs to:
> > 
> > - Find an instantiation point
> > - Match and extract the function decl from the callExpr
> > - Extract function body compontStmt from the function decl at that point the check owner likely knows pretty well what they're doing and shouldn't be surprised that analyze results conflicts if they happen to also analyze an uninstantiated version.
> > 
> > Repository:
> > 
> >   rCTE Clang Tools Extra
> > 
> > https://reviews.llvm.org/D50883





Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D50883