[PATCH] Initial pass at API design for DebugInfo/PDB

David Blaikie dblaikie at gmail.com
Tue Feb 3 15:19:10 PST 2015


On Tue, Feb 3, 2015 at 3:11 PM, Zachary Turner <zturner at google.com> wrote:

> ================
> Comment at: include/llvm/DebugInfo/PDB/IPDBRawSymbol.h:193
> @@ +192,3 @@
> +  virtual bool isVirtualInheritance() const = 0;
> +  virtual bool isVolatileType() const = 0;
> +};
> ----------------
> dblaikie wrote:
> > How're these functions going to communicate failure?
> Undefined in theory, probably false in practice.  You shouldn't call
> methods on the raw interface unless you know it's a valid method.
>
> For the purposes of a dumper who wanted to detect unknown / unexpected
> fields, that knowledge could all be encapsulated in the implementation of
> the raw interface.  For example, you could have PDBSymbol::dump() which
> calls RawSymbol->dump(), and that particular implementation can go to the
> native API instead of calling the friendly accessors.
>

Ah - that's a bit different from what I was thinking from our previous
discussion.

If it's undefined behavior, then it might be appropriate to hide
PDBRawSymbol from users entirely - they might as well be casting down to
the specific type and using those functions instead, perhaps? (I was
thinking clients would be able to use PDBRawSymbol and just call all the
functions and swallow the failures when they would call the wrong functions)

- David


>
> http://reviews.llvm.org/D7356
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150203/807f6aef/attachment.html>


More information about the llvm-commits mailing list