C++ support questions

[Milian Wolff]

On 02/07/11 16:33, David Nolden wrote:
> 2011/2/7 Esben Mose Hansen<kde at mosehansen.dk>:
>> On Monday 07 February 2011 13:53:44 David Nolden wrote:
>>
>>> If the
>>
>>> namespace context was known, we could somehow pass it to the sub-job
>>
>>> (see sourceNeeded at preprocessjob.cpp:584). Maybe we could add some
>>
>>> ugly hack, to detect "namespace" prefixes without using the parser.
>>
>>> This is not nice though.
>>
>> And you would have the problem again when people decide to do something like
>>
>> class David_Rocks {
>>
>> #include "common_members.h"
>>
>> public:
>>
>> ...
>>
>> };
>>
>> If a crude hack should be made, perhaps it would be best to only divide the
>> parsing of files when the includes are in the top-level scope? That is,
>> between brackets the includes are simply inlined, then processed as a whole.
>> Would that be possible?
>
> Maybe this would be the best option. It would not be possible any more
> to jump to the declarations and/or do refactoring on them, but that
> would be an acceptable tradeoff. Fight uglyness with uglyness. :)
>
> There currently is no working code to do this inline parsing though.
> There might be some remainders of a similar thing from the starting
> time of rpp.

I just encountered the same when using OpenMPI - seems like many 
scientific libraries use such code ;-)

Anyways, I have an idea on how this could be done quite nicely: Could we 
not somehow pass a "parentCtx" to the child job? If it's not set, we 
just assume it's a standalone file. If it is set otoh, we put our 
declarations into that parent ctx.

How this should work:
- all files are parsed once with no parentCtx by the import job
- when we encounter #includes in the top context of a file, assume the 
parentCtx = 0 case and just do what we are doing right now
- otoh, if the #include is in a child context of the current file, 
request a job with parentCtx = 
Indexed/ReferencedDUContext(currentContext()) and continue

this should work properly, including proper "jump to declaration" stuff.

Problems I see:
- once you open that file, you will end up in the "parentCtx = 0" case 
and loose the information about the surroundings. Sounds bearable to me 
though
- when refactoring/looking for uses you will "miss" the others:
namespace A { #include "shared.h" }
namespace B { #include "shared.h" }
int main() { A::doSomething(); B::doSomething(); }
when we e.g. now "rename" A::doSomething, B::doSomething won't be renamed.

Anyways, this should still be better then including the file as macro 
expansion and just offering to jump to the "#include ..." line, or what 
do you think?

bye

-- 
Milian Wolff
http://milianw.de