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

[Konstantin Tokarev]

29.09.2011, 18:41, "Douglas Gregor":
>>>>   It seems to me as there is a danger of keyword misinterpretation in non-QObject contexts.
>>>  I don't see any ambiguity. Can you provide an example?
>>  Since "signals" and "slots" are not language-reserved keywords, there's non-zero probability that some 3rd party can also #define them for some other purposes.
>
> So? You can break any context-sensitive keyword scheme by #define'ing that identifier as a macro.

Ah, that's like #define private public. OK.

> Any code that today defines signals or slots as a macro in a manner that isn't compatible with Qt's use of these keywords, is already broken when using Qt, so we've lost nothing.

Actually this code might not be broken:

1. moc doesn't parse all source code of project: with QMake build system, only headers added to "HEADERS" variable and sources containing #include "something.moc" (with other build system behavior may be different). So it's possible to use Qt in one part of project, and use Qt-incompatible code in others, while building everything with one compiler.

2. There is #indef Q_MOC_RUN which can "protect" some parts of code from moc parsing.

>
>>  So, IMHO it's needed to check if class inherits QObject.
>
> To direct parsing? We don't want to do that, because we can't know whether this class inherits QObject, and we have to decide at parse time what these keywords mean:
>
>         template<typename T>
>         class X : public T {
>         slots: // does X inherit QObject? Maybe it does, maybe it doesn't
>         };
>
> Whether MOC can actually handle this kind of thing today is, IMO, irrelevant; we shouldn't design the feature in a way that's broken in templates.

Thank you for clarification. While it could be useful to prevent code from being incompatible with "traditional" Qt/moc rules (e.g., template cannot contain signals or slots), that could be a task of static analyzer, not regular parser (and we can unleash Qt capabilities if project uses only Clang for compilation).

-- 
Regards,
Konstantin