steakhal wrote: > > 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).
I'm open for suggestions. I also agree that having something similar to conjured would make reasoning more difficult and be a source of confusion. I primarily want to avoid a situation where we can be unsure if this invalidation metadata is present and to what extent it's present. I could repurpose conjured symbols for this, and shove this metadata into it. WDYT about this? @NagyDonat @Xazax-hun I could explore this direction. --- > Are you planning to develop some practical applications of this new > functionality in the foreseeable future? (I really hope that it won't end up > as dead code.) > > I didn't think too deeply about the details of the changes, but most of them > are boilerplate and I feel that even the AI won't mess up such trivial > modifications. I already have a niche checker-specific FP suppression patch in the pipe using this, proving the value. That prompted me playing with the idea of implementing this proposal. https://github.com/llvm/llvm-project/pull/207155 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
