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

[Erik Verbruggen]

On 26 Sep 2011, at 23:30, Sebastian Redl wrote:

> 
> On 26.09.2011, at 22:52, Chris Lattner wrote:
> 
>> On Sep 26, 2011, at 7:02 AM, Konstantin Tokarev wrote:
>>> 26.09.2011, 15:04, "David Chisnall" <csdavec at swan.ac.uk>:
>>> 
>>>> 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?
>>> 
>>> "signals" and "slots" annotations are currently used by Meta-Object Compiler (code generating tool which is part of Qt).
>>> 
>>> Attribute-based annotations will be used by Qt Creator to provide code completetion, and it can be used in other tools (e.g. code analysis tools) which need to inspect Qt code and use advanced Clang capabilities in the same time.
>> 
>> I haven't looked at the patch in question, but it seems reasonable to add some sort of qt_foobar attribute if it substantially improves QT development.
>> 
>> Random thought experiment: would it be possible to kill off MOC entirely (at least when building with Clang)?
> 
> In theory, easily so. MOC just writes out C++ code which is then compiled in turn, so a Clang extension could just generate the relevant AST in memory and compile it along with the primary class.
> 
> It would be even better to have this as an AST-processing plugin, though.

Well, from a high level: yes. But as always, it is in the details. One of the obviously missing things is an attribute for use in/with the Q_OBJECT macro. For my current use-case (the Qt Creator IDE) I/we do not need that (yet). But a/the more hairy one is Q_PROPERTY:

class Foo: public QObject { Q_OBJECT
    Q_PROPERTY(int width READ width WRITE setWidth NOTIFY widthChanged)
};

For the compiler, this macro expands to empty. But moc actually parses it. I implemented it with in Qt Creator for our current parser, and the syntax is roughly that after the lparen there has to be a (variable) declaration, the parameter-pack for the read/write/notify method is optional (but for the write/notify method it can be a maximum of 1). So this would require to either properly parse it, or to be able to get the macro contents (with the macro recorder, which is currently only used when the parser is instantiated by libclang) and then re-parse it in a plug-in. (Oh, and the read/write/notify methods/slots have to be declared, obviously.)

And no, I did not want to do that (yet?)...

That said, the Q_PROPERTY is probably the most complex case. So after tackling this case, AST generation would not be rocket-science (nor brain surgery).

-- Erik.