Support for member specialization roadmap/workarounds
deadlocklogic opened this issue · 6 comments
This is already mentioned:
Support for member specialization: members of a template can be specialized separately, this is not supported.
But is it a limitation from clang
or missing
for the time being in cppast
?
Consider:
template <class T> struct Temp1{
template <class T> struct Temp2{
};
};
using DeepNested = Temp1<int>::Temp2<int>;
Even thought cpp_type_alias::underlying_type()::primary_template()::no_overloaded()
is 1
.
Any ideas if this would be implemented in the future?
Are there any workarounds?
Basically consider these 2 files:
File1:
namespace ns {
template <class T> struct Temp1 {
template <class T> struct Temp2 {};
};
} // namespace ns
File2:
namespace ns {
using DeepNested1 = Temp1<int>::Temp2<int>;
using DeepNested2 = ns::Temp1<int>::Temp2<int>;
} // namespace ns
I can't figure out how to resolve DeepNested1
, at least I want the referring template entity of Temp2
(Temp1
is ok too, basically I want to know in which scope the referring type resides) so I can workout a hacky way around parsing type arguments.
All I need is to know which template entity Temp2
refers to.
@foonathan Any thoughts?
I don't think libclang provides APIs to handle it. This might be possible to fix with #120.
@foonathan Why not using dump-json
just to get around this libclang
limitation?. Because the feature/json
branch is far from complete. So instead of writing huge chunk of it, just patch the current implementation?
Thanks again, this library is really useful but still needs the last part of the puzzle.
It's not easy to mix the two modes, I might as well just add another "backend." Yes, progress is slow, PRs are welcome. ;)
Yes of course PR are awesome!
I would really like to dig into a libtooling
backend but I have trouble setting it up (what I am doing is using their setup for building with ninja + hacking around CMake
to use VS as IDE).
dump-json
can be feature complete and probably I have to study it myself more.
But the big question is: can the dumped data be easily navigated? Because it is funny if a json
can provide infos better than libclang
itself. I guess I should take a look first maybe. 😭
I will try to study the feature/json
branch and see how things are working there.
I would really like to dig into a libtooling backend but I have trouble setting it up (what I am doing is using their setup for building with ninja + hacking around CMake to use VS as IDE).
Yes, this is one of the reason I'm not using libtooling: it's not really designed for projects that live outside the clang source tree. The API is also unstable.
But the big question is: can the dumped data be easily navigated? Because it is funny if a json can provide infos better than libclang itself. I guess I should take a look first maybe. sob
I'm using simdjson, which parses it on demand during navigation. It's a bit finicky at times, but otherwise works well.