Community
Participate
Working Groups
Checkout llvm, clang, clang-extras. Use the new C/C++ wizard, create an Existing CMake project that points at the llvm directory. Hit the build button in the launch bar to build. That creates the compile_commands.json file that is feeds the compile commands to the indexer. In the clangd source there is a source file ASTManager.cpp. I find that symbols defined in the clangd directory, e.g. DocumentStore and JSONOutput, are not discovered. And, actually, Open Type doesn't find them either. BTW, if you don't want to install the CMake plug-ins, importing this as a Makefile project seems to produce the same result.
Maybe it'll work when Open Type is powered by clangd :p (Sorry, couldn't resist.)
LOL :).
I got it to index OK. One problem was conflicting std::vector typedefs in the clang-tidy tests. I'll come back to you with the exact setup once I have it in front of me.
Thanks Marc-Andre. The CMake plug-in worked great. Hopefully we can make this work with it.
Ah, I tried on macOS and I do see tons of errors. Not sure what the difference is (with Linux) but it might be something in standard libraries throwing the indexer off.
(In reply to Marc-André Laperle from comment #5) > Ah, I tried on macOS and I do see tons of errors. Not sure what the > difference is (with Linux) but it might be something in standard libraries > throwing the indexer off. Perhaps a gcc/libstdc++ vs. clang/libc++ thing? Are you using master or 9.2.1? I fixed some issues related to parsing libc++ headers in bug 511108.
I'm on the 9.2 branch. master should be better?
(In reply to Doug Schaefer from comment #7) > I'm on the 9.2 branch. master should be better? The specific libc++ issue I was thinking of (bug 511108) was back-ported to the 9.2 branch. I've generally tried to backport fixes to name resolution bugs to the 9.2 branch whenever possible, so I wouldn't expect the master branch to be significantly better at this stage, although that may start to happen going forward as the 9.2 branch is closed now.
OK I didn't have the same exclusions on both of my workspaces. If I exclude llvm/tools/clang/test and llvm/tools/clang/INPUTS then it works properly. And the indexer preference "Index source files not included in the build" has to be disabled of course. Ideally, I would like to just exclude a handful of huge input files so that the index is still built for tests. It's useful to be able to see how an API is used in tests as an example and disabling the index on them makes this more difficult.
(In reply to Marc-André Laperle from comment #9) > Ideally, I would like to just exclude a handful of huge input files so that > the index is still built for tests. It's useful to be able to see how an API > is used in tests as an example and disabling the index on them makes this > more difficult. What is an example of a test that uses an API directly? I thought the tests were mostly C++ files that are run through the compiler.
(In reply to Nathan Ridge from comment #10) > (In reply to Marc-André Laperle from comment #9) > > Ideally, I would like to just exclude a handful of huge input files so that > > the index is still built for tests. It's useful to be able to see how an API > > is used in tests as an example and disabling the index on them makes this > > more difficult. > > What is an example of a test that uses an API directly? I thought the tests > were mostly C++ files that are run through the compiler. You're right, I see the source files in llvm/tools/clang/test are not using the API, llvm/tools/clang/unittests does contain code that uses the API but I don't need to exclude that one. So all is good.
