Disable Eclipse's error discovery. (Codan false positives)

Question

My experience until now is, that the error discovery of Eclipse is horribly buggish without any solutions (Tried __GXX_EXPERIMENTAL_CXX0X__, -std=c++0x

Answer 1

UPDATE: It's been a long time since I posted the original answer and it has become outdated. I double-checked today (Mar 15, 2014): in Eclipse Kepler (Build id 20130614-0229) it is sufficient to

• add under Project > Properties > C/C++ Build > Settings then on the Tool Settings tab GCC C++ Compiler > Miscellaneous the -std=c++11 flag,

• then under Window > Preferences > C/C++ > Build > Settings on the Discovery tab chose CDT GCC Built-in Compiler Settings and add the -std=c++11 flag to Command to get compiler specs. On my machine it looks like this after the change:

  ${COMMAND} -E -P -v -dD -std=c++11 "${INPUTS}"

• clean and rebuild both your project and your index (Project > C/C++ Index > Rebuild) as Eclipse tends to cache error messages and show them even though they are gone after changing the settings.

This works on my machine for sure. If it doesn't on yours, then you might want to give a shot to this: C++11 full support on Eclipse although I am neither sure about the correctness of this approach nor was it necessary to do it on my machine. As of March 7, 2014 users claim that it helped them whereas the above approach didn't.

---

_{The original post from 2012, now outdated:}

These bogus errors come from Codan. I also issued a bug report (C++03!!!) but the same problem shows up in the latest stable Eclipse so I don't think much has happened :(

Workaround:

Click on the project properties, then C/C++ General > Code Analysis > Syntax and Semantic Errors and deselect whatever false errors you are getting.

I just want to see solely real compiler errors

Of course, you can disable there the static analysis completely, in that case you can accomplish exactly what you want.

---

UPDATE: 2 users have reported that what Jeevaka wrote helped them. I have tried what he wrote, it did not help me with Juno SR1 and CDT 8.1.1. Perhaps Codan developers have improved static analysis in Juno SR2 and CDT 8.1.2

Answer 2

I was troubled by Cordian errors for c++11 code that compile perfectly in gcc with all warnings enabled as well. I found what I think is the root cause, at least it was in my case. Few other questions on Cordian errors for c++11 are closed as duplicates of this question and point to this question. So I though I would post my answer here.

This is what I found: Project Properties > C++ General > Preprocessor … > Entries > GNU C++ > CDT GCC Builtin Compiler Settings has *__cplusplus=199711L* as one of the entries.

I changed it as follows: In the Window > Preferences > C/C++ > Build > Settings > Discovery tab selected CDT GCC Builtin Compiler Settings and changed ${COMMAND} -E -P -v -dD ${INPUTS} to ${COMMAND} -E -P -v -std=c++11 -dD '${INPUTS}'. Then hit Apply. The errors were gone after next build.

I am using Juno SR2 with CDT 8.1.2 and handmade make files.

Adding a little more color:

I am no expert, but here is what I think happened in my case:

Cordian gather errors in multiple ways.

One is parsing the compiler output. -std=c++11 in my Makefile ensured that this part worked right all along as invoking the same Makefile through terminal didn't flag any errors.

Another is through 'Code Analysis'. For this, and probably for other tasks, Ecplise need to know the settings that compiler would use. Eclipse find these by invoking the command I edited above and parsing the output. By ticking the 'Allocate console in the Console View' before hitting 'Apply' it is possible to view the output of this command. These settings include include directories and defines such as __cplusplus. When these match what gcc would use when invoked through my Makefile the results are consistent.

When I was experimenting with the problem using #pragma message inside headers I thought __GXX_EXPERIMENTAL_CXX0X__ is what is wrong and saw some online suggestions for setting this manually, but that seemed to be a workaround as well.

Answer 3

You can also remove problematic parts of code from the CDT scope by fllowing next steps: