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:
- install latest eclipse CDT - Oxygen 4.7.2 / build id 20171218-0600
- gcc 6.1 only compiler visible in system path - defaults to c++14 standard without the need for explicit
-stdflag
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;} 
