[Qt-creator] QtCreator C++ code parser and clang integration status

[Thomas Gahr]

On Wednesday 01 February 2012 18:27:21 Flex Ferrum wrote:
[snip]
> >> Yes, I forgot all the Qt macros which are not only "macros".
> >> For this stuff the existing parser could be used. But having
> >> two parsers running also complicates things.
> 
> I think, this task may have another solution. SLOT (and any other
> identifier) is just a macros which could be expanded in many different
> ways.
> 
This is interesting, I've been thinking about this problem for a little while 
following this thread and I also thought that it is certainly possible to 
somehow tell clang to override the macro definitions of SIGNAL and SLOT to 
expand to something different, something different that makes clang provide the 
correct information.
But (I think) the expansion for SLOT(foo(int)) where foo is a member of say 
struct Bar would need to be something like:
(void(Bar::*)(int) &Bar::foo)
to
a) let clang know that foo(int) is referring to member function Bar::foo
b) disambiguate possible overloads of Bar::foo - Bar::foo(double) 
Bar::foo(int) or whatever
and I can't think of any legal macro-trickery to produce such an expansion.
Leads to the idea: have the sources "pre-pre-processed" before having clang 
parse it to translate everything SLOT(...) or SIGNAL(...) to something clang 
would understand.
Worth the effort? Stupid? I don't know, I am simply interested to hear if 
anybody could think of an elegant way of tricking clang to "swallow" SLOT and 
SIGNAL.

Another possibility would be to go ahead and have clang understand this kind 
of "keyword" but that would mean patching clang's sources since keywords need 
to be known at the time of compiling clang which surely is not an option.

Regards,
Thomas
> Best regards,
> Flex Ferrum
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator