Hi Richard,<br><br>I am not sure if it is possible to reject the attributes before finishing parse of declarators, because we should only reject attributes appertain to declarations, not to definitions, and I believe we don't know if a declaration is a definition or not until the parsing of the declarator is finished. Thus, it seems reasonable to put the checks after function declarators are fully parsed.<br>
<br>Attach tweaked patch that coveres all cases you mentioned. <br><br>Cheers<br>Michael<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 8:42 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Nov 26, 2012 at 6:43 PM, Michael Han <span dir="ltr"><<a href="mailto:fragmentshaders@gmail.com" target="_blank">fragmentshaders@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Richard,<br><br>I haven't looked into check it in Sema yet. I had the impression that this type of checks should be performed in parser if possible. Here is what I am thinking.<br><br>There are two cases to deal with here<br>


- attributes appear before decl specifier of function:<br>
  [[]] friend into foo();<br>  This case can already be detected in parser using ParsedAttributesWithRange.<br><br>- attributes appear after function declarator id<br>  friend int foo [[]] ();<br>  Attributes in this case are parsed as part of parsing function declarator, so we need some way to pass the parsed attributes to caller where the syntactic checks are handled. I was using AttributeList for this. Without using it, it seems there are two additional options:<br>


Update Declarator so it can return a list of source ranges of C++11 attributes that appertain to the declarator, as the source ranges are what's required to emit the "attributes not allowed here" type of diagnostic. <br>


<br>Or<br><br>Update ParseDeclarator so it takes an additional parameter of ParsedAttributesWithRange. It's probably not worth doing so as  ParseDeclarator is invoked in a lot of places and this second parameter will only be useful once.<br>


<br>What do you think? I can look into sema check if that is the right direction to go.<br></blockquote><div><br></div></div><div>Hmm, how about rejecting the attributes in the first case after parsing the decl-specifier-seq and before parsing any declarators, and rejecting the attributes in the second case by checking whether you have a friend declaration inside ParseDirectDeclarator? We should only produce one diagnostic for this:</div>

<div><br></div><div>[[noreturn]] friend void f(), g();</div><div><br></div><div>... but we should produce two diagnostics for this:</div><div><br></div><div>friend void f [[noreturn]] (), g [[noreturn]] ();</div></div>
</blockquote></div><br>