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

[Douglas Gregor]

On Sep 28, 2011, at 12:12 PM, David Blaikie wrote:
> On Wed, Sep 28, 2011 at 10:50 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 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.
> 
> Out of curiosity, how would this satisfy criteria (4) of the clang language extension guidelines ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016275.html ) - would this be practically standardizable? (it certainly fulfills several, perhaps all, of the other criteria - existing community, etc)

Sadly, it would not satisfy criteria (4), and we would have to live with that, because it's clearly not something that the committee would ever standardize. The Qt developers of old did us all a grave injustice in the first place by #define'ing lowercased identifiers and then having the gall to become wildly popular, so we're fairly stuck now: either we do some attribute trickery and keep on defining "signals" and "slots", or we introduce a not-likely-to-ever-be-standardized feature to make existing Qt code work better and reclaim "signals" and "slots" in the process. 

> Is it possible to support C++11 attributes (& namespaced attributes) as an extension in C++03, or does that break other things? Seems a pity to further extend an extension that's been superseded by a standard feature.


We could probably support C++11 attributes in C++03; I don't think it actually breaks anything.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110928/ebe0459e/attachment.html>