Current revision do not use lldb type summaries for simple types with no children (like function pointers). So this patch makes MI use lldb type summaries for evaluation of all types of objects, so MI own formatters are no longer needed.
abidh ki.stfu granata.enrico
- rL251082: [lldb-mi] display summary for simple types + refactor (use lldb formatting…
rLLDB251082: [lldb-mi] display summary for simple types + refactor (use lldb formatting for…
rGb91779eb28c4: [lldb-mi] display summary for simple types + refactor (use lldb formatting for…
To my understanding this is not needed (see comment below)
unsigned - not. signed -yes. One question: if I register summary for "char" - it will not be called for "unsigned char" and "signed char", right?
I think the signedness of char depends on the implementation. Which means that "char" will cover one of them, but not the other. Which is why I was suggesting adding "char", "signed char" and "unsigned char". Just to cover all bases.
Correct. It will only be called for an exactly matching type name. We strip "useless" qualifiers like "volatile" and "restrict" before doing format matching. But, for obvious reasons, not signed and unsigned.
Well, if you add separate formatters for signed char vs. unsigned char, then they will know of course
Please also indicate if a revision is dependent on some other revisions that has not yet been committed as this one is on D13657.
As the condition is changed, can you explain a little bit in which scenario, you want to pass true/false here for first parameter.
Same as above.
This is "get summary whenever possible, unless explicitly told otherwise".
So false is only passed when character type is evaluated and m_bHandleCharType is false. I do not fully understand why this boolean flag exists - may be performance reasons?
In case one day someone create summary provider for some pointer type which is not char*, wchar_t* and related, it will be handled by MI correctly. The only exception is if we have char pointer and explicitly told not to handle char type
Review updated to reflect Enrico comments regarding signed/unsigned char.
Now all character types are evaluated as ASCII code (signed or unsigned) + value.
Additional method introduced to SBValue to check if type is signed or unsigned integer
Greg pointed me to SBType::GetBasicType() - this will return to you one of
such that you don't need to add new API to get this information
Also, even if this were necessary, it would go on SBType, definitely not SBValue