Ok that was it, it was because my type was called Class.  Oops!<br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 4:28 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Most C++ classes and C structs don't have data formatters, particularly not classes that you write yourself.  <br>
<br>
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.<br>
<br>
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.<br>
<br>
--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.<br>
<br>
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):<br>
<br>
(lldb) type summary info myClass<br>
summary applied to (Class) myClass is:  (not cascading) (hide value) (skip pointers) (skip references) Class summary provider<br>
(lldb) type synthetic info myClass<br>
synthetic applied to (Class) myClass is:  Class synthetic children<br>
<br>
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".<br>
<br>
What do you get from that?<br>
<br>
Jim<br>
<br>
> On Oct 26, 2018, at 3:34 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> <br>
> 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:<br>
> <br>
> (lldb) type category list<br>
> Category: default (enabled)<br>
> Category: VectorTypes (enabled, applicable for language(s): objective-c++)<br>
> Category: system (enabled, applicable for language(s): objective-c++)<br>
> <br>
> 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?<br>
> <br>
> On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> Remove the "not"...<br>
> <br>
> Jim<br>
> <br>
> > On Oct 26, 2018, at 10:24 AM, Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> > <br>
> > 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.<br>
> <br>
<br>
</blockquote></div>