Bugzilla – Full Text Bug Listing
| Summary: | IDE shows source has errors, but it builds without errors | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jacob Dall <jd> |
| Component: | cdt-codan | Assignee: | CDT Codan Inbox <cdt-codan-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | Elena Laskavaia <elaskavaia.cdt> |
| Severity: | normal | ||
| Priority: | P3 | CC: | a.spam.filter, aleherb+eclipse, angvz, b8666307, cdtdoug, chris.burguera, christelle.burguera, Daniel.Savard, dank, dponomarev, eichelberg, ian.d.mccallum, jd, jesper, jessica.zhang, kff, malaperle, mariusmuja, mikael.delacour, ribonucleico, richardhickling, salvatore.culcasi, tcb, williamsiddall, yevshif, zanetu, zeratul976 |
| Version: | 8.0 | ||
| Target Milestone: | 8.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Attachments: | |||
Created attachment 199325 [details]
Screendump of the reported errors in the IDE
Looks like codan problem markers are created multiple times and not cleaned up properly. The sample code works for me, though. I'd try to delete all problem markers and rebuild the index of the project (right click on project > Index > Rebuild). Moving to cdt-codan. I'm sorry, but I don't follow... please let me know how to "delete all problem markers". Thanks Rebuilding the index makes no diffence what so ever. (In reply to comment #3) > I'm sorry, but I don't follow... please let me know how to "delete all problem > markers". Select the markers in Problems Tab and hit "Delete" button. Just keep in mind that you can't delete a category ("Errors") but individual markers only. (In reply to comment #2) > I'd try to delete all problem markers and rebuild the index of the project > (right click on project > Index > Rebuild). I deleted the markers, but they reappear when I rebuild the index. I also tried to delete the markers, skip the index rebuild and instead request a build of the project - here the markers also reappears. I wonder, since the sample code works for Mr. Leherbauer, if this is project setup related. So I created a new C project and added the sample code. And instantly the error markings showed. I've attached the project. If Mr. Leherbauer could please try with that project and report the outcome. Created attachment 199395 [details]
Eclipse project for testing the error markings
Created attachment 199798 [details]
error report in Eclipse
eclipse.buildId=I20110613-1736
$ uname -a
Linux xxxxx 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 21:48:33 +0200 i686 i686 i386 GNU/Linux
I am getting the same type of error report when the compiler shows no errors. I am attaching a screenshot of what I see in Eclipse.
Using the test project (errors are reported about_tm sec etc) - remove/comment out the <memory.h> include - rebuild index (freshen all files) no more errors - undo the change (include <memory .h>) - rebuild index (freshen all files) no errors, even closing/opening the project, the errors are gone. 64-bit version, always reproducible, gcc 4.5.. I'm new to this, so I do not know if I should have filed a new bug report, but I think I've run into the same issue: The editor marks errors in the code, but it compiles nicely. Again the issue involves <time.h> where the editor does not find the definition of CLOCK_REALTIME. The problem is triggered by the following two-liner:
#include <time.h>
int x = CLOCK_REALTIME;
I've also added the project files.
*Speculation warning on*
I've been digging around in the headers a bit, and it appears that the definition for CLOCK_REALTIME sits in <bits/time.h>, inside of a conditional
#ifndef __need_timeval
...
#endif
Apparently, Eclipse believes that __need_timeval is defined at this point, but I can't see it being defined before the include of <bits/time.h>. However, <bits/time.h> is also included later, with __need_timeval being defined (and subsequently undefined, I think). Can it be that Eclipse gets confused by the same header being included multiple times with different sets of symbols defined?
*Speculation warning off*
Version info for platform:
> uname -a
Linux valdemar 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Version info for Eclipse:
Eclipse Platform
Version: 3.7.0
Build id: I20110613-1736
Version info for CDT:
Eclipse CDT P2 Customizations for SDK installation
Version: 1.0.0.201109151620
Created attachment 206849 [details]
Minimal example showing problems for the editor with <time.h>
Here is the minimal example as an Eclipse project. I hope I've packaged it correctly.
I'm running into this, too. Just adding the lines #define _POSIX_C_SOURCE 200809L #include <time.h> int blah1 = CLOCK_REALTIME; int blah2 = CLOCKS_PER_SEC; to the Hello, World project shows the problem; all three of those symbols are marked as unresolved, but building works fine. This is on ubuntu 11.10 with a fresh indigo sr1 cdt installed from eclipse.org. To be more specific, I'm using Build id: 20110916-0149. It seems there a multiple active bug reports for the same problem. I am new here, what is the correct way to merge multiple pug reports? (In reply to comment #13) > It seems there a multiple active bug reports for the same problem. I am new > here, what is the correct way to merge multiple pug reports? If the errors you are seeing are not related to time.h, then you should probably create a new bug. The errors feed off the parser/indexer and it's likely that is has different bugs that should be addressed separately. That said, chances are this was fixed part of bug 197989. If you could try the nightly build that would be great: https://hudson.eclipse.org/hudson/job/cdt-nightly/ It's a zipped p2 repo that you can use in Help, Install new software, Add, Archive. The nightly build definitely improved the problem. I cleaned my projects and then only one had a lot of invalid compile problems in the margin and in the problems view. It is a math library shared object project. I rebuilt a gfx library that uses the math library and it cleared out all the problems. Which is odd as the problems were in cpp files as well as headers. I suppose I am expecting a lot of the IDE to keep track of the compile problems in different libraries when referenced by two different executable projects. What is the design behavior if you switch between two projects that both have different compile errors? Had similar problems with: cdt-nightly #953 Feb 5, 2012 9:14:10 PM $ uname -a Linux derivative 2.6.35-31-generic-pae #63-Ubuntu SMP Mon Nov 28 20:48:50 UTC 2011 i686 GNU/Linux I've encountered the same problem and solved it by changing the order of the headers that are included upfront.
Project->Properties->Indexer:
"Files to index up-front"
Put ctime at the beginning of the list.
Hi, Mikael's workaround, i.e. putting ctime at the beginning of the list, works for me as well. Environment: Debian Wheezy eclipse 3.7.2 eclipse-cdt v8.0.2 Linux 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux I've been a similar issue with the printf function which could not be resolved. Adding stdio.h to the beginning of the list of files to index up-front solved the issue for me as well. I have the same problem running under Juno/CDT 8.1. But the solution does not work since the "Index up-front" option is now gone. Created attachment 217324 [details]
putting ctime at the beginning of the list
Mikael Delacour 2012-03-25 08:04:24 EDT
I've encountered the same problem and solved it by changing the order of the
headers that are included upfront.
Project->Properties->Indexer:
"Files to index up-front"
Put ctime at the beginning of the list.
(In reply to comment #20) > I have the same problem running under Juno/CDT 8.1. > But the solution does not work since the "Index up-front" option is now gone. Hi Jesper, See the attachment titled "putting ctime at the beginning of the list". Dear Missing Name, this bug is against Codan 8.0. My comment concerns Codan 8.1. I made it anyway to highlight the fact that the problem still exists in 8.1, but the solution is no longer possible, since the input field "Files to index up-front" DOES NOT EXIST in 8.1. (In reply to comment #23) > Dear Missing Name, this bug is against Codan 8.0. My comment concerns Codan > 8.1. I made it anyway to highlight the fact that the problem still exists in > 8.1, but the solution is no longer possible, since the input field "Files to > index up-front" DOES NOT EXIST in 8.1. I run the same configuration as yours and I fixed the problem the following way: Project --> Properties --> C/C++ General --> Indexer I checked the Enable specific project settings box (could be changed for the workspace as well) and then I checked the box: Index source and header files opened in editor. Give it a try and let us know if it solves your problem. (In reply to comment #24) > (In reply to comment #23) > > Dear Missing Name, this bug is against Codan 8.0. My comment concerns Codan > > 8.1. I made it anyway to highlight the fact that the problem still exists in > > 8.1, but the solution is no longer possible, since the input field "Files to > > index up-front" DOES NOT EXIST in 8.1. > > I run the same configuration as yours and I fixed the problem the following > way: > > Project --> Properties --> C/C++ General --> Indexer > > I checked the Enable specific project settings box (could be changed for the > workspace as well) and then I checked the box: Index source and header files > opened in editor. > > Give it a try and let us know if it solves your problem. Sorry for false hope, after further testing creating another type it seems the problem reappears for the new type but not for the former one which was previously at problem. Seems there is something wrong with the indexer. I've tried all of the code examples and projects in this bug with CDT 8.2 (Kepler), and I'm not able to reproduce any of the reported errors. There have been a lot of improvements to the indexer between Indigo (the latest version at the time of reporting the bug) and Kepler. Can anyone still reproduce any of these problems with Kepler? I'm going to mark this as fixed as of 8.2 because the cases mentioned work (according to Nathan). I also don't think it's a good idea to have a bug this generic "IDE shows source has errors". I think some people in CC/votes are actually seeing different parser/indexer bugs and it would be much better if they where reported individually. So if you are still seeing an error, please create a new bug report with a specific bug description and if possible with sample code. |
Build Identifier: I20110613-1736 In a project containing the below shown code, the project is marked as having errors. But it compiles without any errors. <code> #include <stdio.h> #include <memory.h> #include <time.h> typedef struct { struct tm dt; } foo_t; int main (int argc, char **argv) { time_t rawtime; foo_t foo; time(&rawtime); memcpy(&foo.dt, gmtime(&rawtime), sizeof(struct tm)); printf("utc time is %02d%02d%02d\n", foo.dt.tm_hour, foo.dt.tm_min, foo.dt.tm_sec); return 0; } </code> An error marker on the printf line says: Multiple markers at this line - Field 'tm_sec' could not be resolved - Field 'tm_min' could not be resolved - Field 'tm_hour' could not be resolved This issue is present in both the 32 and 64 bit version of eclipse. Reproducible: Always Steps to Reproduce: 1. Open project containing the shown source 2. Notice that errors are reported 3. Build it 4. Notice that it builds without errors