CODEWITHSUNDEEP
eclipsec++14eclipse-cdt
Xeren Narcy
Xeren Narcy

Reputation: 875

Eclipse CDT parser support for c++14

Good old disconnect between what the compiler deems valid and what the IDE thinks... Before you introduce duplicate questions / answers, I must stress that everything available on the issue here and elsewhere I have already tried and distilled to this setup:

Checking the log for compiler settings discovery, it's configured correctly for C++14:

03:51:39 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
g++ -E -P -v -dD C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/lib -L/c/mingw610/prerequisites/x86_64-zlib-static/lib -L/c/mingw610/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.1.0 (x86_64-posix-seh, Built by MinGW-W64 project) 
COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-shared-libgcc' '-mtune=core2' '-march=nocona'
 C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/6.1.0/cc1plus.exe -E -quiet -v -P -iprefix C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/ -D_REENTRANT C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -mtune=core2 -march=nocona -dD
#define __STDC__ 1
#define __cplusplus 201402L
(etc)

The following snippet compiles (with unused variable warning but nonetheless), but eclipse highlights issues with resolving test in int main:

auto test (auto N) {return N;}
int main () {
  auto z = test( 3U );
  return 0;
}

The parser log gives:

Unresolved names:
   Attempt to use symbol failed: test in file ...

The IDE shows this in problems:

Invalid arguments '
Candidates are:
? test(?)
'

For all intents and purposes eclipse is in fact seeing the correct gcc binary, and is using the correct c++ standard, but still not conforming to the compiler per evidence above (unless I missed something?).

Any ideas how to make eclipse behave with syntax parsing given it's already got the right c++ standard version?

I get the feeling it's an issue with the indexer rather than the parser, since it has no trouble figuring out the number of arguments or the declaration but can't seem to make sense of functions with auto return type that depends on an auto-typed argument.

UPDATE

It may be related to this bug (looks to be fixed) and this followup bug (still ongoing, test case given is similar to mine).

However, this version of test does not give me problems, so I'm unsure if it's the same bug or something else...

template< typename T > auto test (T N) {return N;}

Upvotes: 1

Views: 379

Answers (1)

HighCommander4
HighCommander4

Reputation: 52739

auto in the parameter type of a function (as opposed to a lambda) is not standard C++14.

It's supported by the Concepts TS (which is supported by GCC >= 6 with the -fconcepts flag), and accepted by GCC >= 4.9 even without -fconcepts as an extension, but it's not standard. (It may become standard in C++20, along with some other parts of the Concepts TS.)

For example, here's what Clang (which does not support this extension) says about your code in C++14 mode:

test.cpp:1:12: error: 'auto' not allowed in function prototype
auto test (auto N) {return N;}
           ^~~~

Eclipse CDT does not currently implement this extension either. I filed bug 532085 to track adding support for it; contributions are welcome!

Upvotes: 2

Related Questions