[cfe-dev] Proposal: parsing Qt signals/slots with attributes

Douglas Gregor dgregor at apple.com
Thu Sep 29 22:34:45 PDT 2011


On Sep 29, 2011, at 7:34 AM, Erik Verbruggen wrote:

> Hi all,
> 
> So to sum up the options from both the mailing-list and irc, I can go either of these routes:
> 
> 1) just go with attributes as with my first patch
>    - pro: only a few changes to go, and it is done
>    - con: yet another toolkit specific extension which doesn't help everyone
> 2) implement GCC's user attributes:  __attribute__((user("your_funky_attribute")))
>    - pro: more GCC compatibility, also useful for projects already using it (i.e. Mozilla)
>    - con: would need significantly more work than the other routes
>    - con: very GCC and very non standard, possibly obsoleted by:
> 3) c++0x attribute namespaces
>    - pro: very standard
>    - con: support seems to be minimal (if I got it right), so needs some work
>    - con (?): c++0x specific, so we would need to support it for other language standards than just c++0x
> 
> So, before I spend time implementing all of them, what is the best way (or "the clang way") to go?

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:

	#define Q_OBJECT __attribute__((annotate("qt_object")))

Then, you patch need only:
  
  (a) add support for parsing attributes on access specifiers, and
  (b) update libclang to expose the "annotate" attribute 

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.

	- Doug




More information about the cfe-dev mailing list