1

I've read over tons of questions about the cdt indexer, and none of them get to the point. I've configured all of the preprocessor include paths and providers and all that and I have it all working.

But there are some modules that the compiler is okay with that the indexer is not, and I'd like to be able to see the compile output (if that's what's going on) that the indexer is getting that is causing it to fail. If I saw what it sees as the syntax or semantic or whatever kind of failure, I can change the code to make the indexer happy, but I haven't found a way to get the output other than the "problems" view, which only tells you what it found, not WHY it found it as a problem.

Does such a view exist? Is there really a g++ compile going on or is there really a c++ parser that is compiler-like but not a compiler that is trying to parse the source code and getting errors that there is no compiler output for?

stu
  • 8,461
  • 18
  • 74
  • 112

1 Answers1

0

The indexer is not invoking the compiler to produce diagnostics. It has its own C++ parser.

Cases where the indexer gives an error where the compiler does not can be do to incorrect project configuration, or a bug in CDT's C++ parser. Note that CDT's C++ parser does not yet support all C++14 and C++17 features, so code using such features is likely to run into such issues.

If you have a reduced testcase which compiles but triggers an indexer error, I would encourage you to file a CDT bug report.

HighCommander4
  • 50,428
  • 24
  • 122
  • 194
  • very cool, that's what I wanted to know. Okay, I've got a few cases where it goes south, I'll try and reproduce a open a bug, thanks. – stu Jul 08 '18 at 00:29
  • so I updated to eclipse photon and now all the things that wouldn't index magically index perfectly. Problem solved, thanks. – stu Aug 08 '18 at 14:24
  • @stu Yup, I guess due to Photon's improvements in C++14 and C++17 support. Glad to hear it's working for you now! – HighCommander4 Aug 08 '18 at 18:03