Community
Participate
Working Groups
I have a project with C++ and C files. The code compiles and runs correctly, but I need to get rid of the following error: Symbol 'ERANGE' could not be resolved I was able to reproduce it with these two files (latest x64 Elipse Juno on Ubuntu, with CDT 8.1.2): main.h: #ifndef MAIN_H_ #define MAIN_H_ extern "C" { #include <errno.h> } #endif /* MAIN_H_ */ main.cpp: #include <cerrno> #include <cassert> #include "main.h" int main(int argc, char * argv[]) { assert(errno != ERANGE); // <-- CDT ERROR here return 0; } The following workarounds to similar issues DID NOT work: - Setting Indexer -> Use active build configuration - Manually adding the ERANGE symbol to project Paths and Symbols - Adding main.cpp to Preferences -> C/C++ -> Code Analysis -> Symbol is not resolved -> Customize Selected... -> Scope -> Exclusion patterns The only solution that will work is disabling the Symbol is not resolved error completely, but that will cause me to miss real issues.
I can confirm the bug for ERANGE, and add another one which seems be related : #include <tuple> int main(int argc, char * argv[]) { std::tuple<int, int> t = std::make_tuple<int, int>(0, 0); // <-- ERROR 1. return 0; } ERROR 1. : "Symbol 'make_tuple' could not be resolved" In both cases selecting "Open definition" leads to the right header file and line. I am running Eclipse 4.2.2 with CDT 8.1.2 on Ubuntu 12.10
Reduced: a.hpp: #ifndef A_HPP #define A_HPP #include "b.hpp" #endif b.hpp: #ifndef B_HPP #define B_HPP #undef ERANGE #include "c.hpp" #endif #define THIS_FILE_IS_NOT_PRAGMA_ONCE c.hpp: #ifndef C_HPP #define C_HPP #define ERANGE 34 #endif test.cpp: #include "b.hpp" #include "a.hpp" int i = ERANGE; // ERROR: Symbol 'ERANGE' could not be resolved Looks like an indexer issue, and related to handling of significant macros. cc'ing Markus.
(In reply to comment #1) > #include <tuple> > > int main(int argc, char * argv[]) > { > std::tuple<int, int> t = std::make_tuple<int, int>(0, 0); // <-- ERROR 1. > return 0; > } > > > ERROR 1. : "Symbol 'make_tuple' could not be resolved" > > In both cases selecting "Open definition" leads to the right header file and > line. > > I am running Eclipse 4.2.2 with CDT 8.1.2 on Ubuntu 12.10 This works fine with Kepler (CDT 8.2).
I am experiencing this problem with CDT version 8.2.1.201309180223 and Ubuntu 12.04. I am able to get to the correct file via a succession of 'Open Declaration' operations on 'errno.h', which goes through 4 or 5 files to reach the declaration. Other declarations that are in a place similar to ERANGE in /usr/include/x86_64-linux-gnu/bits/errno.h, e.g. EDOM and EILSEQ, are similarly not found by Eclipse. These symbols are explicitly undeffed, then subsequently redefined in another file or later in the same file, depending on other defines. I suspect that that this complexity is not properly handled.
I have seen this in CDT 8.3.0.201402142303. The symbol declarations are found (F3), but I was getting these errors until I set, in Project, Properties, C++ General, Code Analysis, Launching, to "Run with Build". BTW I could not find the equivalent setting in the workspace.
Created attachment 249753 [details] Bug snapshot I can confirm the bug presence for CDT 8.5.0.20140917 in eclipse Luna 4.4.1. I had it in my actual project but also I was able to reproduce it with the short example from the first post.
This bug still exists in Mars. It is easily reproducible. Have any devs even taken a look in this thread yet?
(In reply to Peter Levine from comment #7) > This bug still exists in Mars. It is easily reproducible. Have any devs > even taken a look in this thread yet? I'm not very familiar with this part of CDT's code (handling of includes and macros), but this is on my list of bugs to look into, if someone else doesn't beat me to it.
Has there been any progress on this bug since 2013? It's been a while since I've used Eclipse for development, and I was happy to be getting back into it with a new job, but really surprised when I created a project in Neon.2 for some existing code and straight-away found it littered with hundreds of "errors" -- all of them basic failures to resolve types. In files that directly include headers like stdio.h, sys/socket.h and netdb.h, I'm getting failures to resolve types like socklen_t, members of hostent, and defines like SOCK_STREAM. Heck, it's not able to resolve FILE and "stderr"! The editor is peppered with so many red type resolution error markings that real errors would not be readily visible, making this feature (which in the past I've used heavily) essentially unusable. Of course, this is all in relatively simple C code (not even getting into C++) that compiles correctly with no errors or warnings. Most types in the code do resolve, and I can find no pattern to distinguish between them and those that don't. I've looked at quite a few discussions of this issue, here and in StackExchange threads, and all of them seem, from my perspective, to be kind of missing the point. None of the (many!) proposed resolutions work, and, critically, it seems there simply shouldn't be any possible configuration setting under which a source file in a properly-compiling project that includes stdio.h could cause an error in resolving "FILE". I'd really like to have more context to understand how this is happening. From what little I can currently see, this doesn't seem related to project settings, reindexing or telling CDT when to rerun the analysis, it just seems like a fundamental failure of the CDT code analysis routines to correctly parse C code.
(In reply to Chris Robison from comment #9) First, please note that this bug report concerns an error in a very specific scenario involving an #undef and a header file without pragma-once semantics (as demonstrated in the reduced example in comment 2). It is not an umbrella bug report for false positive errors with the message "Symbol could not be resolved". I've edited the bug report's summary to clarify this. The errors you describe indicate a different issue, likely with your project setup. If you give some details about your project setup - preferably in a new bug report - such as what type of project you are using (managed build vs. makefile), what platform / compiler / standard library, and so on, I can try to help you fix them. > critically, it seems there simply shouldn't be any possible configuration > setting under which a source file in a properly-compiling project that > includes stdio.h could cause an error in resolving "FILE". The compiler needs some configuration to compile your project properly: default include paths, built-in macros, and so on. Eclipse needs this same configuration info to understand your code the same way the compiler does. If the project is not set up in such a way that Eclipse has the same configuration info as your compiler, then Eclipse can have trouble understanding your code the way your compiler does.
