[cfe-commits] [PATCH] Add support to VS debugger for previewing SmallString<>

David Blaikie dblaikie at gmail.com
Wed May 16 15:31:10 PDT 2012

On Wed, May 16, 2012 at 2:31 PM, Will Wilson <will at indefiant.com> wrote:
> On 3 May 2012 19:40, Will Wilson <will at indefiant.com> wrote:
>>>>>> For Visual Studio users: Here's little patch to the
>>>>>> clangVisualizers.txt that allows the contents of a SmallString to be
>>>>>> seen in string form, rather than (somewhat less usefully) as a
>>>>>> SmallVector.
>>>>> I assume this wouldn't work for SmallStrings that include embedded
>>>>> '\0' characters? Though I suppose we don't do any better for StringRef
>>>>> either, so perhaps that's not a priority.
>>>> Unfortunately not, I can't find any support for anything other than
>>>> basic zero-terminated strings in the syntax.
>>> I don't know anything about VS, really, but SmallStrings are not usually null-terminated. Have you tested this when there is definitely something after the string?
>> Yes, in such cases you see whatever follows the string data. Therefore
>> (as with StringRef) you need to be careful interpreting the string
>> data in the debugger preview. That said, I'd far rather have the
>> utility of seeing it displayed as a string with garbage at the end
>> than have to interpret it as an array of characters. And either way,
>> you may still view it as an array by expanding the string node to show
>> the underlying view of the SmallVector<> which also lets you see the
>> true extent of it.
>> So it's definitely imperfect, but better than nothing :)
> Any thoughts on getting this committed? It's pretty minor but helpful.

Sorry, just lost track of it. Committed as r156959.

> Incidentally, I could look at writing a custom debug plugin in the
> future to deal better with StringRef and it's relatives in VS.

Sounds good - I don't personally use VS for development, but happy to
throw these in.

[maybe I mentioned this already & it was refuted, but: It'd be nice if
they could use some common functionality (it's weird that visualizing
a derived class can't use a base class's visualization behavior by
default... but perhaps that makes sense, I'm not sure - if not by
default, perhaps explicitly just by casting to the base)]

More information about the cfe-commits mailing list