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

[Douglas Gregor]

On Sep 20, 2011, at 1:10 AM, erikjv wrote:

> Hello,
> 
> I would like to add support for recognising Qt's signal/slot mechanism to clang by using attributes. For that, I have a proposal for a few small changes to the clang parser. These changes use the attributes to mark AST nodes as signal/slot/invokable, and expose those attributes through libclang.
> 
> A bit of background: if you are more familiar with Objective-C, then the signal/slot mechanism works nearly exactly the same as Cocoa's IBAction/IBOutlet: it uses a meta-type system to invoke the methods, or let slots connected to a signal know that the signal was emitted. Qt's meta-type system also allows for "invokable methods", which can be called/invoked without being tagged as slot.
> 
> Example:
> 
> class Test {
> public:
>     Q_INVOKABLE void invokableA();
> 
> public slots:
>     void slotA();
>     void inlineSlotB() {}
> 
> signals:
>     void signalC();
> 
> private:
>     Q_SIGNAL void signalD(), signalE();
>     Q_SLOT void slotF(), slotG();
>     void not_a_slot_or_slot();
>     Q_SLOT void inlineSlotH() {}
> };
> 
> (To be used properly with Qt, the class would also have to inherit from QObject, and have the Q_OBJECT macro right after the opening brace.)
> 
> Taking a leaf from Cocoa's book, we can use the pre-processor to inject:
> 
> #define signals protected __attribute__((q_signal))
> #define slots __attribute__((q_slot))

Alright, since there haven't been enough crazy ideas today… I think we should consider defining 'signals'  and 'slots'  as context-sensitive keywords, rather than handling these as attributes on the access specifier. The grammar is fairly simple, and one need only look ahead a single token (to the ':') to determine whether we have the signals or slots keyword (vs. using it as an identifier). It shouldn't be much more work than threading attributes through the access specifiers like you've already done.

IMO, the end result would be much cleaner than having to #define signals and slots (#define'ing Q_SIGNAL, Q_SLOT, etc. is fine by me), and has the added benefit of  helping resolve my longstanding grudge with Qt :)

  http://www.boost.org/doc/libs/1_47_0/doc/html/signals/s04.html#id2861476

	- Doug