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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
