Would citing PR20455 help? It wasn't actually my primary motivation but it's not too far off. Having the template parameters there lets you know what's going on in the DWARF, without having to fetch and parse the name string of every struct you come across. Actually I'm not sure parsing the name string is unambiguous either; each parameter is either a typename, or an expression, but without the parameter DIEs you don't know which, a-priori. (What does <foo> mean? Depends on whether you think it should be a type name or a value; you can't tell, syntactically, you have to do some lookups. Ah, but if you had the parameter DIEs, you would Just Know.)
Choosing to emit a forward/incomplete declaration in the first place fails source fidelity, but it is a practical engineering tradeoff of compile/link performance against utility; and, after all, the source *could* have been written that way, with no semantic difference. But, if we're going to emit a white-lie incomplete declaration, we should do so correctly. --paulr P.S. We should talk about this forward-declaration tactic wrt LTO sometime. I have a case where a nested class got forward-declared; it's entirely conceivable that the outer class with the inner forward-declared class would end up being picked by LTO, leaving the user with no debug info for the inner class contents. From: David Blaikie [mailto:dblai...@gmail.com] Sent: Wednesday, November 04, 2015 8:30 PM To: reviews+d14358+public+d3104135076f0...@reviews.llvm.org; Robinson, Paul Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters. On Wed, Nov 4, 2015 at 5:53 PM, Paul Robinson via cfe-commits <cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>> wrote: probinson added a comment. GCC 4.8.4 on Linux doesn't produce these, but DWARF 4 section 5.5.8 says a class template instantiation is just like the equivalent non-template class entry, with the exception of the template parameter entries. I read that as meaning an incomplete description (i.e. with DW_AT_declaration) lets you omit all the other children, but not the template parameters. As usual, I think it's pretty hard to argue that DWARF /requires/ anything (permissive & all that). And I'm not sure that having these is particularly valuable/useful - what use do you have in mind for them? Wouldn't hurt to have some size info about the cost here, though I don't imagine it's massive, it does open us up to emitting a whole slew of new types (the types the template is instantiated with, and anything that depends on - breaking/avoiding type edges can, in my experience, be quite beneficial (I described an example of this in my lightning talk last week)). I don't think omitting the template DIEs was an intentional optimization, in the sense of being a decision separate from deciding to emit the incomplete/forward declaration in the first place. They were just omitted because we were omitting everything, but everything turns out to be non-compliant. http://reviews.llvm.org/D14358 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
