Ok that was it, it was because my type was called Class. Oops!
On Fri, Oct 26, 2018 at 4:28 PM Jim Ingham <jing...@apple.com> wrote:
> Most C++ classes and C structs don't have data formatters, particularly
> not classes that you write yourself.
>
> The way value printing works in lldb is that we start by making the
> ValueObject for the value from its Type, so at that stage it is just a
> direct view of the members of the object. That is done without help of the
> data formatters, reading instead directly from the object's type. Then we
> consult our type match -> summary/synthetic children registries and we
> construct a summary or a set of "synthetic children" (or both) for the
> object if we find any matches there. Then the ValueObjectPrinter prints
> the object using the Type based ValueObject, the Summary and the Synthetic
> Children, and there's a print options object that says whether to use the
> raw view, the summary and/or the synthetic children.
>
> But for a type lldb knows nothing about, there won't be any entries in the
> formatter maps, so you should just see the direct Type based children in
> that case.
>
> --raw sets the right options in the print option object to get the printer
> to just use the strict Type based view of the object, with no formatters
> applied.
>
> In your case, you used "Class" as your type name and Class is a special
> name in ObjC and there happens to be a formatter for that. You can always
> figure out what formatters apply to the result of an expression with the
> "type {summary/synthetic} info" command. For your example, I see (my
> variable of type Class was called myClass):
>
> (lldb) type summary info myClass
> summary applied to (Class) myClass is: (not cascading) (hide value) (skip
> pointers) (skip references) Class summary provider
> (lldb) type synthetic info myClass
> synthetic applied to (Class) myClass is: Class synthetic children
>
> On macOS those summary/synthetic child providers are in the objc
> category. The info output should really print the category as well, that
> would be helpful. But you can do "type summary list" and then find the
> summary in that list and go from there to the category. Ditto for "type
> synthetic".
>
> What do you get from that?
>
> Jim
>
> > On Oct 26, 2018, at 3:34 PM, Zachary Turner <ztur...@google.com> wrote:
> >
> > So, the second command works, but the first one doesn't. It doesn't
> give any error, but on the other hand, it doesn't change the results of
> printing the variable. When I run type category list though, I get this:
> >
> > (lldb) type category list
> > Category: default (enabled)
> > Category: VectorTypes (enabled, applicable for language(s):
> objective-c++)
> > Category: system (enabled, applicable for language(s): objective-c++)
> >
> > So it looks like the behavior I'm seeing is already with the default
> category. Does this sound right? Which code path is supposed to get
> executed to format it as a C++ class?
> >
> > On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham <jing...@apple.com> wrote:
> > Remove the "not"...
> >
> > Jim
> >
> > > On Oct 26, 2018, at 10:24 AM, Jim Ingham <jing...@apple.com> wrote:
> > >
> > > But at the minimum, not loading formatters for a language that we can
> determine isn't used in this program seems like something we should try to
> avoid.
> >
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
