[PATCH] D76801: [AST] Print a<b<c>> without extra spaces in C++11 or later.

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 17 15:48:02 PDT 2020


dblaikie added subscribers: tamur, cmtice, JDevlieghere, labath, probinson, aprantl.
dblaikie added a comment.

In D76801#1989641 <https://reviews.llvm.org/D76801#1989641>, @sammccall wrote:

> Sorry about the problems here, and thanks for letting me know...
>
> In D76801#1989421 <https://reviews.llvm.org/D76801#1989421>, @rnk wrote:
>
> > We updated the compiler and break some VS std::map visualizers:
> >  https://crbug.com/1068394
> >  I haven't 100% confirmed that this caused the issue, but looking at the code suggests that the names in our codeview output changed, which I would consider to be a regression. This should've been caught by clang's test suite. We already have codeview tests that try to ensure clang prints debug info names following MSVC's exact spacing, but apparently none broke, so this area was under-tested. I wonder if gdb or other DWARF consumers might be affected by this formatting change.
>
>
> I've got a sinking feeling that I misunderstood the implications of updating CodeGenCXX/debug-info-template-explicit-specialization.cpp and the Modules/*DebugInfo.cpp tests.
>  I assumed that these were human-readable names, not things that tools rely on. As you say maybe the dwarf changes broke things.
>  I don't really know much about debug info, @dblaikie do you think the DWARF changes in those tests are safe? If not, should I be documenting/mitigating this or trying to undo it?


( @aprantl @JDevlieghere @probinson @cmtice @tamur @labath )

In general DWARF doesn't specify this at all. In reality, at least GDB does some fuzzy matching - I don't know about LLDB and SCE (Sony's debugger).

GDB's fuzzy matching seems sufficient to make this work/not be a problem here.

Here's one example of testing that. Compile these two files with different compilers (either Clang<with this patch>+GCC, or Clang<with>+Clang<without>):

  template<typename T>
  struct tmpl {
    int member = 42;
  };
  
  const tmpl<tmpl<int>> *get_obj() {
    static tmpl<tmpl<int>> t;
    return &t;
  }
  int get_mem(const tmpl<tmpl<int>> *t) {
    return t->member;
  }

  template<typename T>
  struct tmpl;
  
  const tmpl<tmpl<int>> *get_obj();
  int get_mem(const tmpl<tmpl<int>> *t);
  
  int main() {
    const tmpl<tmpl<int>> *x = get_obj();
    return get_mem(x);
  }

Then launch that in a debugger & stop in main, print the type of 'x' - it should include the int member named 'member':

  type = const struct tmpl<tmpl<int> > [with T = tmpl<int>] {
      int member;
  } *

If the debugger can't associate the type in the two files together, then the type of 'x' would print out as an incomplete type (you can test this by compiling the first file without debug info):

  type = const struct tmpl<tmpl<int>> {
      <incomplete type>
  } *




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76801/new/

https://reviews.llvm.org/D76801





More information about the cfe-commits mailing list