This is an archive of the discontinued LLVM Phabricator instance.

Improved Visual Studio 2015 visualization of SmallVectorImpl
ClosedPublic

Authored by mspertus on Jun 10 2016, 7:57 PM.

Details

Summary

When visualizing small vectors in VS2015, show the first few elements in the DisplayString instead of the size. For example, a SmallVector of DeclAccessPair will visualize like

{public typename ...Ts, public typename U}

The visualization in VS2013 remains the same because we continue to include the old visualizer with a lower-than-default priority of MediumLow, and the same SmallVector would continue to be visualized as

{size = 2}

I decided to submit this one for review before commit because as SmallVector is used pretty much everywhere in LLVM and Clang, even though I think this is a huge improvement in practice but wanted to give others a chance to pipe in if they disagree. If no one pipes in, I plan to go ahead and commit in 48 hours

Diff Detail

Event Timeline

mspertus updated this revision to Diff 60434.Jun 10 2016, 7:57 PM
mspertus retitled this revision from to Improved Visual Studio 2015 visualization of SmallVectorImpl.
mspertus updated this object.
mspertus added a subscriber: cfe-commits.
mspertus accepted this revision.Jun 12 2016, 6:50 PM
mspertus added a reviewer: mspertus.

No adverse (or otherwise) comments received, so committing as revision 272525

This revision is now accepted and ready to land.Jun 12 2016, 6:50 PM
mspertus closed this revision.Jun 12 2016, 7:01 PM

revision 272525

As for the original change proposed: My guiding principle would be "do
whatever std::vector does". (& that's what I did when implementing GDB
pretty printers for SmallVector/SmallString/ArrayRef, etc... )

An aside: We generally don't do time limited reviews like this. Either
something needs review because you're not sure about it, or it doesn't. It
sounds like the feedback you were looking for probably would've been fine a
post-commit review feedback just as easily & perhaps might've been a better
option. (while in this case it was fine - it's sort of a community
habit/standards thing - we don't want to create the idea that lack of
feedback is consent/approval in the review process)