<html><body><div>On 07 Oct, 2011,at 10:32 PM, Douglas Gregor <dgregor@apple.com> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br>
On Oct 6, 2011, at 2:12 AM, Erik Verbruggen wrote:<br>
<br>
> On 30 Sep, 2011,at 07:34 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" _mce_href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br>
> <br>
>> Let's use the existing "annotate" attribute, which is a bit like the "user" attribute mentioned in (2) above, but already implemented in Clang. That way, Qt can have definitions such as:<br>
>> <br>
>> #define Q_OBJECT __attribute__((annotate("qt_object")))<br>
>> <br>
>> Then, you patch need only:<br>
>> <br>
>> (a) add support for parsing attributes on access specifiers, and<br>
>> (b) update libclang to expose the "annotate" attribute <br>
>> <br>
>> That should be sufficient, requires much less effort (and risk) than most of the other solutions, and won't require us to bring anything related to Qt into Clang itself.<br>
>  <br>
> Attached is a new patch, which adds parsing of attributes after a C++ access specifier. These attributes get propagated in the same manner as the access specifier.<br>
<br>
I see that this handles, e.g.,<br>
<br>
        public slots:<br>
<br>
(with the attribute definition of "slots", of course)<br>
<br>
but it doesn't seem to handle, e.g.,<br>
<br>
        signals:<br>
<br>
I assume you want to address that as well?</div></div></blockquote><span> </span></div><div>qobjectdefs.h uses:</div><div><div>#   define slots</div><div>#   define signals protected</div></div><div><br></div><div>so with attributes one can use:</div><div><div>#   define slots __attribute__((annotate("qt_slot")))</div><div>#   define signals protected __attribute__((annotate("qt_signal")))</div></div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br>
> Then in c-index-test I changed the spelling of the annotate attribute to return the quoted string.<br>
<br>
That makes sense, thanks.<br>
<br>
> Question: should I add a check to disallow attributes other than the annotate attribute after an access specifier?<br>
<br>
Yes. I'd like us to enable such attributes on a case-by-case basis, rather than deal with the fallout of them all implicitly propagating.</div></div></blockquote><span> </span></div><div>Ok, added it.</div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br>
Minor nit:<br>
<br>
@@ -2139,10 +2146,19 @@ void Parser::ParseCXXMemberSpecification(SourceLocation RecordLoc,<br>
         CurAS = AS;<br>
         SourceLocation ASLoc = Tok.getLocation();<br>
         ConsumeToken();<br>
-        if (Tok.is(tok::colon))<br>
-          Actions.ActOnAccessSpecifier(AS, ASLoc, Tok.getLocation());<br>
-        else<br>
+<br>
+        AccessAttrs.clear();<br>
+        MaybeParseGNUAttributes(AccessAttrs);<br>
+<br>
+        if (Tok.is(tok::colon)) {<br>
+          Decl *xsDecl = Actions.ActOnAccessSpecifier(AS, ASLoc,<br>
+                                                      Tok.getLocation());<br>
+          if (AttributeList *Attrs = AccessAttrs.getList())<br>
+            Actions.ProcessDeclAttributeList(Actions.CurScope, xsDecl, Attrs,<br>
+                                             false, true);<br>
+        } else {<br>
           Diag(Tok, diag::err_expected_colon);<br>
+        }<br>
<br>
<a href="http://llvm.org/docs/CodingStandards.html#ll_naming" _mce_href="http://llvm.org/docs/CodingStandards.html#ll_naming">http://llvm.org/docs/CodingStandards.html#ll_naming</a><br>
<br>
suggests that "nsDecl" be named starting with a capital letter.</div></div></blockquote><span> </span></div><div>Changed it to AccessDecl.</div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br>
We also seem to be missing tests.<br></div></div></blockquote></div><div><span><br></span></div><div>Should be included now Attached patch is against r141497.</div><div><br></div><div>-- Erik</div></body></html>