vsk added a comment. In https://reviews.llvm.org/D43912#1023078, @jingham wrote:
> In https://reviews.llvm.org/D43912#1022916, @aprantl wrote: > > > > Going forward, we should transition to a model in which CompilerTypes are > > > either valid or do not exist. > > > > I don't understand very well how the LLDB type system works so excuse my > > naive questions: Does this account for lazyness? I.e., could there be value > > in having an unverified type that might be sufficient for what LLDB is > > trying to do with it, where validating it (which may involve recursively > > materializing all of its children) might fail? I could imagine that for > > some use-cases just knowing the size of a type would be sufficient. > > I guess what I'm trying to say is: Are there code paths in LLDB that do > > something useful with a type where `type.IsValid()==false` ? > If we discover code like this, transitioning the code into a model where types are force-checked will require caution, but would still be possible/desirable. For example, we could refactor the operations on invalid type s.t they use a different type, i.e one without the same validity requirement as CompilerType. > No, I don't think so. Laziness might make a type go from valid (we only got > the forward type) to invalid if the attempt to complete it fails for some > reason (base class missing, for instance). But a not yet fully completed > type will call itself valid, not invalid. Thanks for the explanation Jim! https://reviews.llvm.org/D43912 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
