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

[André Pönitz]

On Wednesday 01 February 2012 19:02:41 ext Flex Ferrum wrote:
> 2012/2/1 André Pönitz <andre.poenitz at nokia.com>:
> > On Wednesday 01 February 2012 16:13:20 ext Thomas Gahr wrote:
> >> 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)
> >
> > The expansion _is_ a string literal.
> >
> > But one could probably "fake" a pointer-to-member-function, but that
> > would require the definition of 'Bar' being accessible for further processing
> > later on, which is, however,  not needed in a Qt context, and e.g. Qt Creator's
> > "weak  plugin dependencies" are consciously(!) exploiting this fact.
> Just imagine what during clang processing "SLOT(foo(int))" is
> expanding into something like this:
> 
> __qtcreator_this_class_method_ref_as_slot(foo(int))

It doesn't get expanded as that.

After clang (or any "real" preprocessor for that matter) had its go, it's 
essentially 'some_function("some_string_literal")'.

You'd now "just need  to parse the string lteral and add the resulting data 
to clang's code model". 

This is far from trivial, and it's part of the price you pay for a generic external 
tool that doesn't understand nor care for your specific context.

> AST processor/analyzer (e.g. cppeditor plugin) handles this case as a
> special case and does corresponding work.


> When the same code is processed by the compiler, "SLOT(foo(int))" is
> expanded to a string literal.

That's unrelated. The compiler will _always_ see "2foo(int)"
 (or "2foo(int)\0" __FILE__:...  for !QT_NO_DEBUG), no matter what the IDE does.

Andre'