diseraluca wrote:

>  I still do not see why the proposed solution would not work. If it solves 
> the minimal case that you provided in the description of this PR, I am afraid 
> that there is some bit from the Qt setup that we do not understand.

I cannot for certain say if there is an issue or not with how the Qt codebase 
is setup; but I think it is out of the scope of the task we are trying to solve 
to change that based on the behavior of QDoc interoperations with Clang.

For what it is worth, I've been playing with a very small example to check a 
few possibilities, and even excluding explicit specializations we still have 
certain cases that are not stable.

Say in

#pragma once

template<typename T>
class QList {
        using Foo = const T&;

        void begin(Foo);

Adding something as `using Bar = QList<int>;`, and this being the only code in 
the translation unit, we still have the addition of such a line modifying our 
output, qualifying the type of the first parameter of `begin` as 
`QList<int>::Foo`, even with your proposal.

Say we can stabilize that, so that it always qualify in the same way, say 

If we are documenting, maybe, some method `QList::Foo QList::bar()` and 
we show to the user the return type as `QList<int>::Foo`, this is going to be 
albeit not as erroneous as the `QFuture<void>` case, for our user.

Indeed, the return type of `bar` really depends on the instantiation of `QList` 
that we are looking at and it would be extremely confusing for a user skimming 
our documentation to think that it always returns a `QList<int>::Foo`.
As a documentation generator we really want to look at the generic case for our 

Now, say we have a very stable output, albeit not adequate for our case, it 
might simplify doing some postprocessing to qualify in the way we want, but at 
that point we still need to maintain something relatively similar to 
`getFullyQualified*`, thus why it isn't that much of a difference for our use 
case to only have a more stable output.

There are some other cases that might be iffy for our use-case too, with this 

Thus why I think, albeit unfortunate, our use-cases just happen to be somewhat 
in conflict with regards to the output of `getFullyQualified*`.

@vgvassilev  Both me an my team are deeply thankful for your help. It was 
really kind to try and find a solution for our case.

I will close this PR as I don't think it can be merged, as it would break other 
people use cases.
I will leave it open 1 or 2 days more in case someone else wants to chime in 
with something.

cfe-commits mailing list

Reply via email to