diseraluca wrote: > @diseraluca, thanks for the thorough description. The point of these routines > is to produce code that compiles. I am not sure if we change `Foo<int>::Bar` > with `Foo<T>::Bar` it will compile. > > > Due to the way the current codebase is set up, the chosen specialization is > > `QFuture<void>` so that, for example, `QFuture::constBegin()` would be > > shown to the user as returning a `QFuture<void>::const_iterator`. > > Nonetheless, `QFuture<void>` is the only specialization that cannot have a > > `const_iterator` and, as a consequence, doesn't have a `constBegin` method > > in the first place. > > I suspect that `QFuture<void>` is an explicit specialization. The intent of > the code was to pick up an implicit specialization which follows much more > closely the template pattern. Would selecting the first non-explicit > instantiation fix your usecase?
Thank you for your answer @vgvassilev. I gave it a quick try, and we would still end up with the same result in our codebase. But, generally, this would not probably be feasible for us as a solution. Since that is the case, and we have somewhat conflicting requirements, I think the best path would be for me to indefinitely maintain a custom implementation of `getFullyQualified*`, leaving upstream as is. I would thus suggest to close this without merging. https://github.com/llvm/llvm-project/pull/67566 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
