[clang] [analyzer] Introduce the invalidation artifact symbol (PR #207155)

[Donát Nagy via cfe-commits]

NagyDonat wrote:

> > My immediate reaction is that if this "mirrors" Conjured symbols, then why cannot this be a subtype of `SymbolConjured`? Did you think about this option and reject it for some reason?
> 
> I think they are orthogonal, and is-a relationship wouldn't be correct there. It would certainly make the migration easier, but IMO it wouldn't be a great fit.

As I think more about this, I'm still not convinced about the independence of Conjured and InvalidationArtifact symbols. I understand that conceptually there is no "is-a" relationship between these two types -- but on a practical level they behave very similarly, which is admitted e.g. by the doc-comment of `SymbolInvalidationArtifact`:
>  Behaves like SymbolConjured but additionally carries an InvalidationCause describing why the invalidation happened, and (when known) the symbol that was bound to the region just before the invalidation.

I think it is clear that these two classes have some shared behavior (which is not shared by other symbols) -- for which the theoretically accurate model (which prevents code duplication) would be introducing a common parent class for them.

However, if I understand correctly, `SymbolConjured` wouldn't have any additional behavior compared to this common parent, so we would get a situation that is very close to "SymbolConjured is a parent of InvalidationCause" (but you would have the separate type `class SymbolConjured : public ConjuredOrInvalidation` for values that are known to be "real" conjured values).


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