search

standardese / cppast

Library to parse and work with the C++ AST
Other
1.7k stars 164 forks source link

Support for member specialization roadmap/workarounds #127

Open deadlocklogic opened 2 years ago

deadlocklogic commented 2 years ago

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?

deadlocklogic commented 2 years ago

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?

foonathan commented 2 years ago

I don't think libclang provides APIs to handle it. This might be possible to fix with #120.

deadlocklogic commented 2 years ago

@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.

foonathan commented 2 years ago

It's not easy to mix the two modes, I might as well just add another "backend." Yes, progress is slow, PRs are welcome. ;)

deadlocklogic commented 2 years ago

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.

foonathan commented 2 years ago

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.