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

Erik Verbruggen erik.verbruggen at me.com
Tue Sep 27 11:21:12 PDT 2011


On 26 Sep 2011, at 13:04, David Chisnall wrote:

> I'm not sure what you mean by this.  There isn't any fancy stuff in clang that is exclusive to Apple's implementation of Objective-C - clang supports the (GNUstep) open source implementation of Objective-C to the same degree that it supports Apple's.
> 
> The closest thing that comes to mind is the handling of IBOutlet and IBAction.  These were macros in OpenStep and with clang can expand to attributes, but they have no effect on compilation.

Bingo (see below).

> It would help if you could explain what you want to use these attributes for (i.e. why would clang supporting them in the parser help you).  The IBAction / IBOutlet support is there to allow the various ad-hoc Objective-C parsers that understood these macros to continue to understand them when switching to libclang.  What tools does Qt use that need to understand these annotations?  

Like I said in the original email: we prototyped/implemented an integration of clang into Qt Creator as a replacement code model. One of the missing pieces is to have context-sensitive completion for signals/slots while using clang. For example, when doing code-completion with the current code model for:

    connect(theButton, SIGNAL(<here>

or:

    connect(theButton, SIGNAL(clicked()), this, SLOT(<here>

Qt Creator filters the results to only show signals (in the first case) or slots (in the second case). Now to do this, Qt Creator needs to know if completion result (meaning: a declaration) is tagged as either a signal or a slot (or neither).

The patch implements this by doing the same as IBAction/IBOutlet for method declarations/definitions. However, Qt/moc allows for defining whole groups of methods as signals/slots by using the "signals" access specifier (which normally gets expanded to "protected") and "public/protected/private slots" (where slots gets expanded to empty). And this is also the biggest difference with IBAction/IBOutlet. So the patch also handles:

class Checkbox: public QObject {
protected __attribute__((q_signal)): // expanded from "signals"
  void checked();
public __attribute__((q_slots)): // expanded from "public slots"
  void setChecked(bool checked);
};

For the access specifiers, it propagates the attribute to all method declarations following it.

And just like the IBAction/IBOutlet, the attributes are exposed through libclang.

One reason to not add more Q_* macro handling is that Qt Creator does not need it (yet), and because I would like to have it in clang 3.0 (so I can tell users to download that release instead of TOT). So this is a minimal patch to make things work.

Oh, and yes, I work for Nokia as part of the Qt Creator team.

-- Erik.




More information about the cfe-dev mailing list