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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
