ymandel added a comment. In D126973#3558304 <https://reviews.llvm.org/D126973#3558304>, @gribozavr2 wrote:
>> using the StructValue for its properties, while modeling a non-struct type. > > Could you explain the use case in more details? A `StructValue` is used to model a complex underlying type for access to its properties, but the corresponding `AggregateStorageLocation` is not initialized with a record type -- specifically, the real and complex type -- because that type is irrelevant to the model. > Maybe a better change is to move synthetic properties to the base class > `Value`? In part, indeed that's what Gabor suggested above. Please see my response earlier and let me know what you think. In D126973#3556466 <https://reviews.llvm.org/D126973#3556466>, @xazax.hun wrote: > In D126973#3556383 <https://reviews.llvm.org/D126973#3556383>, @ymandel wrote: > >> I'm generally hesitant about assertions that don't enforce necessary >> properties (only "nice"). > > I think not enforcing this in the current model is OK. I am more concerned > about the future if we plan to run multiple checks/modeling in the same fixed > point iteration. One check might make the assumption that the types are > matching up while the other can end up producing values where this is not the > case. Good point -- but I think this gets at a larger issue of how to handle multiple models touching the same type. Even if the types align, for example, the properties might not. So, we need an overall story. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126973/new/ https://reviews.llvm.org/D126973 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits