Eclipse CDT - Method 'endExpression' could not be resolved

[jvitku]

Hi, it seems that (from some, to me unknown reason) the Eclipse is unable to Index the single_include/catch.hpp file. Here is the simple example:

#define CATCH_CONFIG_MAIN
#include "catch.hpp"

unsigned int Factorial( unsigned int number ) {
  return number > 1 ? Factorial(number-1)*number : 1;
}
TEST_CASE( "Factorials are computed", "[factorial]" ) {
    REQUIRE( Factorial(0) == 1 );
}

It compiles and tests OK, but the Eclipse marks all REQUIRE lines as error and complains about Method 'endExpression' could not be resolved.

Tried:

• adding catch.hpp into Preprocessor Include Paths in eclipse
• enabled scalability under C++/editor/scalability to 500000 lines
• rebuilding index, cleaning project, open/close Eclipse..

Setup:

• OS X 10.8.2
• g++-4.8
• Eclipse Juno with CDT

More can be found in Google group

[PureAbstract]

Have you filed a bug report with Eclipse?

[jvitku]

OK, I've also felt like this is a problem rather in the Eclipse CDT indexer, so there it is. We'll see.

[RomainGoussault]

Same issue here

[chvillanuevap]

@kentsangkm's solution in #393 worked for me on Eclipse Luna.

[RomainGoussault]

Same here, I tried #393 solution and it worked on Eclipse Luna, Ubuntu

[philsquared]

I know this has been circulating for a while but I felt there was enough of a critical mass to push it to the top recently. I've now changed the decomposition operator to <=, which I believe works around the issue here?

Please let me know either way - and also whether the change introduces any warnings for you?

[manu-m]

The problem exists since version 1.7.1 again. Is there a chance to "fix" it again in Catch, although in real it is an eclipse problem?

[horenmar]

@manu-m Are you sure its since 1.7.1? Because that one didn't touch the decomposition mechanism. If it started again since 1.7.0, then maybe.

[manu-m]

@horenmar Yes I am sure. I checked it two times again. The message doesn't appear in eclipse while working with Catch 1.7.0 but appears while working with 1.7.1. I am surprised, too.

[horenmar]

@manu-m In that case, probably not. 1.7.0 brought a rework of the expression capture mechanism, which sped up successful assertions significantly (~5 times). 1.7.1 then was a bugfix, so that templated comparisons don't cause compile-time errors.

Maybe we can try to change the underlying operator again, but not sure if that would help.

[horenmar]

@manu-m Try the attached version.

catch.zip

[manu-m]

@horenmar Thank you very much for your extremly fast reply! But unfortunately the attached version still produces the error. Do have another idea or solution related to this problem?

[horenmar]

@manu-m Well, Eclipse could always fix their parser 😄