Possibly relevant information:

John said he thought visualizers were always broken now. But the STL ones work reliably for me in a non-Clang build.

The Chrome-specific visualizers seem completely broken both with and without Clang in VS2017 (I don't have 2015 any more to check). These are the ones in //tools/win/DebugVisualizers. I did some checking and it appears the .natvis files do still get added to the .pdb file.

I think this is supposed to pass the /natvis flags to link.exe: https://cs.chromium.org/chromium/src/tools/win/DebugVisualizers/BUILD.gn?q=natvis+file:%5C.gn&sq=package:chromium&l=10

This seems to be present in the generated .ninja files at least.

This seems to be a problem when the dynamic CRT (/MD) is used. I think gn defaults to component builds, and component builds probably use the dynamic CRT. This is what I see in VS with /MD.

Deleted: string-visualizer-dynamic.png 55.3 KB

	string-visualizer-dynamic.png 55.3 KB View Download

I think this is because the natvis visualizers match the exact type names emitted by MSVC, and clang's type names don't *quite* match MSVC's. Here is a snippet from stl.natvis for visualizing a std::string:
  <Type Name="std::basic_string&lt;char,*&gt;">

Clang emits spaces between template arguments, and MSVC does not. Compare these two lines:
    Name: std::basic_string<char, std::char_traits<char>, std::allocator<char> >
    Name: std::basic_string<char,std::char_traits<char>,std::allocator<char> >

I think this will be easy to fix. We already have a flag in the type printer to help us match MSVC names.

Well, that can't be the cause, since that glob should match regardless of the name spacing. There's more surface-level differences worth investigating, though.

My next theory is that these natvis conditions fail to evaluate:
      <DisplayString Condition="_Mypair._Myval2._Myres &lt; _Mypair._Myval2._BUF_SIZE">{_Mypair._Myval2._Bx._Buf,na}</DisplayString>

_BUF_SIZE isn't mentioned anywhere in clang's debug info for std::string.

So, the next thing to do is to make sure we describe _BUF_SIZE the way that MSVC does in this small example:

struct Foo {
  enum { _BUF_SIZE = 16 };
  int x[_BUF_SIZE];
};
Foo f;

I was able to visualize std::string in a small program after LLVM r310410.

The next thing we need to do is roll clang.

Roll landed Saturday, so this should work now -- at least it does in small programs. Please reopen if you're still seeing issues in this area.