[Qt-creator] RFC: solving the problem of symbol partition to arbitrary files

[Leandro T. C. Melo]

On 06/01/2012 03:56 AM, ext Cristian Tibirna wrote:
> Hello
>
> I almost hijaked the "Switch header/source" thread but then I thought better.
> I guess what follows is a different issue.
>
> Consider a class with template methods, partitioned as follows:
>
> MyClass.h
> --------------------
> #ifndef class_h_already_included
> #define class_h_already_included
>
> class MyClass {
> public:
>    template<typename T>  void template_method(const T&  pT);
>    void normal_method();
> };
>
> #include "MyClass.icc"
>
> #endif
> -----------------------
>
> MyClass.icc
> -----------------------
> template<typename T>  void MyClass::template_method(const T&  pT)
> {
> // stg. here
> }
> -----------------------
>
> MyClass.cc
> -----------------------
> #include "MyClass.h"
>
> void MyClass::normal_method()
> {
> // stg. else here
> }
> -----------------------
>
> The (almost?) usual for classes with public template methods. Given the scope
> of the template method, it has to be available for inclusion, thus defined
> (and not only declared) in the .h.
>
> But, of course, for large classes, with many methods, this can potentially
> polute the .h greatly and thus, a reasonable decision often encountered in
> large projects is to relegate the template methods to a separate "quasi-
> source" file, included at the end of the .h file.
>
> This is all typical (if arbitrary) drill and works perfectly with any
> compiler.
>
> Now, come QtCreator, the .icc files become unfortunately second-class
> citizens. Forget the atypical extension. We could use any of the usual: .hpp,
> .hxx, .hh, .h++, .tpp, .tcc etc (and I tried them). It also doesn't matter to
> what mimetype we stick the .icc extension: src-c++ or src-hdr.
>
> The problem is that the incompletely resolved parsing of the template-defining
> file lets it hanging dry.
>
> It's not like the .h, which has its used declarations included (and resolved)
> from other .h files (with #include directives) or from forward declarations,
> and it's not like the .cc file, which gets its declarations from its own .h
> inclusion.
>
> The use of .icc file introduces problems with symbol following, with
> completions and more. What works:
> - syntax colorisation (partially -- e.g. class attributes are not colorised)
> - symbol resolution for anything that is resolvable from eventual #include
> directives present in the .icc file (not exemplified above)
> - local symbol resolution (local variables)
>
> What doesn't work:
> - header/quasi-source and quasi-source/header switching (with F2)
> - symbol resolution for class attributes (!)
> - symbol searching (with Ctrl+Shift+U or with Ctrl+Shift+F>C++Symbols
>
> I checked that when all the contents of .icc file is relocated in the .h file,
> everything works OK.
>
> I also checked that, given a bit of include-guard sorcery and adding an
> #include directive for the corresponding .h file in the .icc file also works
> around the problems (but this is nor need for the compiler neither in any way
> beautiful or at least excuseable).
>
> Ah, and we don't even need template methods. The same is possible when
> partitioning (this way) inline methods (which also have to provide their
> definitions for inclusion).
>
> I can understand why these functionalities fail: the symbol resolution is
> based on the actual parsing of the full unfolding of the current file. Since
> an .icc lacks (and doesn't need) an #include of the corresponding .h file,
> this mechanism fails.
>
> Unfortunately I know very little of the current parsing code (or the llvm-
> based alternative for what matters).
>
> Thus my question: is this a known issue? (in fact, I know it should be, I
> reported it in QTCREATORBUG-2309). Does somebody have an idea for the actual
> reasons and (mercifully) for eventual solutions?
>

Hi Cristian,

it seems you understand the reason for such behavior yourself. Since 
those symbols are not visible in the .icc (through includes or forward 
declarations) the code model will not be able to resolve everything.

Notice this is actually a broader issue in IDEs, since it's rather 
complex to provide the precise behavior of the compiler. Think of a 
library file, for example, which is included in different projects on a 
session. A more faithful way to edit such a file would require the user 
to specify it should be opened as viewed by this particular project, 
under this particular configuration, under this particular compilation 
sequence.

At the moment I don't see a beautiful solution for this. But one could 
investigate a feasible way to track this kind of inclusions (by 
configuration options or by establishing a convention - notice that 
other file extensions are also used for this purpose) and then feeding 
the relevant file with the necessary information.


Cheers,
Leandro