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

[David Blaikie]

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)

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.

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