[Lldb-commits] [PATCH] D63622: [Target] Hoist LanguageRuntime::GetDeclVendor

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Jun 24 01:06:22 PDT 2019

labath added a comment.

In D63622#1553978 <https://reviews.llvm.org/D63622#1553978>, @jingham wrote:

> The runtime DeclVendor gives runtimes a way to produce type information from runtime metadata.  For instance, the ObjC runtime tables actually have fairly good type information for all ObjC classes - both instance variables, properties and methods.  It is a little lossy, but for instance it knows the return types of methods so with this augmentation users can call ObjC methods without requiring casting...  This is just the code to query the runtime's DeclVendors to see if they know anything about a given typename.
> ObjC is a bit obnoxious, because you can define instance variables and methods in the implementation of a class as well as its interface.  So even though you might have a debug info definition for the type - gotten from including the interface header file - that may not be as good as what you can get from the runtime.  But the runtime type info is, as I said, lossy so if you DO have debug info it will be better.  That means for ObjC you have to do some kind of merge operation to get the best information for a type.  That complexity doesn't affect this patch, but I couldn't resist the opportunity to moan about it a bit since it's given US so much grief over the years!

Thanks for the explanation/background. :)

Comment at: include/lldb/Target/LanguageRuntime.h:137
+  virtual DeclVendor *GetDeclVendor() { return nullptr; }
jingham wrote:
> compnerd wrote:
> > Can this not be `const`?  Seems like retrieving the vendor should not mutate the runtime.
> The vendor is computed lazily, so calling this could cause the vendor to get built.  So formally this is not a const operation.
That depends on how you look at it. If something behaves like "const" from the outside (i.e. doesn't change the abstract state of the object), then I'd be fine with marking it as const even if it needs to modify some internal variables. Lazy evaluation/caching is one of the few valid uses for the [[ https://en.cppreference.com/w/cpp/language/cv | mutable ]] keyword.

However, that wouldn't be very consistent with how the this is done in the rest of lldb.



More information about the lldb-commits mailing list