<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 10:56 AM, Katya Romanova <span dir="ltr"><<a href="mailto:Katya_Romanova@playstation.sony.com" target="_blank">Katya_Romanova@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
Sorry for the delay answering your question about AST.<br>
<span class=""><br>
> > One question, if you're up for it - there is actually an implicit UsingDirectiveDecl in the AST<br>
<br>
><br>
<br>
<br>
</span>..<br>
<span class=""><br>
> > It's possible we could figure out why that decl is being skipped normally? & avoid skipping it/filter it out later for non-ps4 while leaving it in for ps4, rather than synthesizing the extra<br>
<br>
><br>
<br>
> >  imported module from scratch in the debug info code gen?<br>
<br>
><br>
<br>
> >  I took a glance & didn't immediately see why we weren't already visiting this implicit decl - I guess something is filtering out implicit decls somewhere?<br>
<br>
><br>
<br>
<br>
</span>Implicit UsingDirectiveDecl is generated by Sema::ActOnStartNamespaceDef() when it’s given an anonymous namespace.<br>
The UsingDirectedDecl is added to the Parent (top level) which is why you see it in AST dump.<br>
<br>
Above function is called from ParseNamespace(), which is called by ParseDeclaration(). ParseDeclaration() returns DeclGroup.<br>
The problem is that group is populated with a SingleDecl that ParseNamespace returns ([anonymous] NamespaceDecl).<br>
<br>
ParseDeclaration doesn’t know anything about the UsingNamespaceDecl that ParseNamespace implicitly generated<br>
and added to the parent.. This implicit declaration is not added to the DeclGroup and thus you don’t generate<br>
debug node for it.<br>
<br>
If we want ParseNamespace to generate both NamespaceDecl AND an implicit UsingNamespaceDecl<br>
then the following piece of code:<br>
<br>
  case tok::kw_namespace:<br>
    ProhibitAttributes(attrs);<br>
    SingleDecl = ParseNamespace(Context, DeclEnd);<br>
    break;<br>
<br>
should return not the SingleDecl (converted to DeclGroup), but a DeclGroup containing both NamespaceDecl AND UsingNamespaceDecl.<br>
<br>
I think that this fix (conditional for PS4 only) will be more complicated and more invasive solution than FE solution that I implemented before.<br>
<br>
I saw that you already accepted my latest FE patch. Please confirm that you didn't change your mind about how this bug should get fixed after your saw this explanation about AST.<br></blockquote><div><br>After seeing Clang's output on some other code, I'm not sure this fix is correct.<br><br>Could you add a test case with an anonymous namespace inside another namespace? When I tried that with ToT, we /do/ emit the (implicit) using directive today. So your change might cause us to emit two using directives (one marked artificial, and one not).<br><br>So it might be worth figuring out how to plumb through the implicit using directive for the top level namespace so we treat anonymous namespaces the same whether or not they are at the top level, and when making this change - then deliberately suppress the implicit using directive for an anonymous namespace except when targeting PS4/SCE.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If everything is OK, I will rebase and commit my latest FE patch.<br>
Thanks for reviewing!<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D7895" target="_blank">http://reviews.llvm.org/D7895</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>