[Lldb-commits] [PATCH] D43912: [Symbol] Add InvalidType, a force-checked recoverable error

[Vedant Kumar via Phabricator via lldb-commits]

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