<div dir="ltr">Since Phabricator isn't sending email: <a href="https://reviews.llvm.org/D31832">https://reviews.llvm.org/D31832</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 1:54 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is exactly how clang's type printer works, so I'd say this is probably the right implementation strategy. :)<div><br></div><div>Check out clang/lib/AST/TypePrinter.cpp:<br><div><div> class TypePrinter {</div></div><div>...</div><div><div> void printBefore(const Type *ty, Qualifiers qs, raw_ostream &OS);</div><div> void printBefore(QualType T, raw_ostream &OS);</div><div> void printAfter(const Type *ty, Qualifiers qs, raw_ostream &OS);</div><div> void printAfter(QualType T, raw_ostream &OS);</div></div><div>...</div><div><div>#define ABSTRACT_TYPE(CLASS, PARENT)</div><div>#define TYPE(CLASS, PARENT) \</div><div> void print##CLASS##Before(const CLASS##Type *T, raw_ostream &OS); \</div><div> void print##CLASS##After(const CLASS##Type *T, raw_ostream &OS);</div><div>#include "clang/AST/TypeNodes.def"</div></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Apr 7, 2017 at 1:33 PM, Adrian McCarthy via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>I came across a PDB that caused llvm-pdbdump to crash. I tracked it down to a missing overload for a data type in the variable printer. When I tried to provide an implementation, I discovered that there were some bugs in the existing overloads and it was easy to come up with combinations of types that weren't being dumped right. I created some test cases and tried to fix these problems but realized that there's a limitation to how printing the type information is structured.</div><div><br></div><div>The cause of the difficulty is the conflict between these two facts:</div><div><br></div><div>1. C and C++ variable declarations are described inside-out</div><div>2. Printing with color requires printing left-to-right</div><div><br></div><div>Simple types generally work, because all the type information is on the left side, so VariableDumper can just work left-to-right. To handle more complex types (like arrays and function signatures), VariableDumper attempts to special case the complex types. Unfortunately, the special cases can't be combined generally (e.g., making an array of pointers to functions), so it's always possible to find a new bug by adding an extra layer of type information.</div><div><br></div><div>I'm proposing a restructure of VariableDumper (PrettyVariableDumper.cpp) that I think should allow for pretty-printing of all types and actually simplify away most of the special-case code.</div><div><br></div><div>The existing approach is to emit the type information for a symbol and then the identifier, using recursion as necessary to emit the type information of subtypes. For example, if foo is a pointer to an int, it's dumped by first recursively dumping the pointee type (int), then the '*', and then the name (foo). But if bar is a pointer to an array of ints, this breaks down.</div><div><br></div><div>My proposal is to extend this slightly by having dumpers for the "left-side" and the "right-side" of the type information. The pattern for printing a variable them becomes:</div><div><br></div><div> call dumpLeft with the symbol type</div><div> emit the symbol name</div><div> call dumpRight with the symbol type</div><div><br></div><div>Most of the dumpLeft implementations would be identical to the current dump implementations. The default for a dumpRight implementation would be to emit nothing, but for arrays and function signatures, dumpRight would print the bracketed array size and argument lists. This depth-first order of the recursion should produce the necessary output in order, which means there should be no change to how we stream the output in color.</div><div><br></div><div>Any questions, comments, objections?</div></div>
<br></div></div>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>