Community
Participate
Working Groups
If you have a project with a problem in a header file, gcc's output can look like: In file included from intermediate2.h:1, from intermediate.h:1, from tabort.c:1: broken.h:1: parse error before `)' When you turn this into tasks, except for the actual error indication (which is fine) you create a couple of empty tasks for the lines indicating the #include sequence. I would prefer if there was a concept of dependencies between tasks, and that the #include sequence markers were dependent on each other in the following order: Task intermediate2.h depends on task broken.c. Task intermediate.h depends on task intermediate2.h. Task tabort.c depends on task intermediate.h.
Created attachment 3174 [details] Example code with suitable problems
*** Bug 39120 has been marked as a duplicate of this bug. ***
*** Bug 39162 has been marked as a duplicate of this bug. ***
Should be fix in the head branch now. Any of you folks can give it a spin, and tell me it solves the issue. Thanks.
Knowing myself I probably won't be testing this in the near future. Øyvind, do you think you'll be able to verify the fix and post a comment here about whether it worked or not? If not, I'm all for closing this as RESOLVED FIXED anyway. I promise to come back and re-open it if I find it is still a problem.
I'm working intermittantly on my C++ embedded project, but I've saved off two bug-reports that I'll verify in the next week. Øyvind
I tried CDT 1.2.0.7 and the output below does not translate correctly into tasks. Copy & paste from tasks list: Kind Status Priority Description Resource In Folder Location Error no matching function for call to `CommandContext:: InfoCmd.cc firmware/commands line 7 Output from GCC: c:\cygwin\bin\bash --login -c "cd /cygdrive/c/e21/workspace/firmware && ../scripts/build.sh" all Current directory: /cygdrive/c/e21/workspace/firmware Setting up build environment with workspace in /cygdrive/c/e21/workspace Running make rm -rf output/version.o mkdir --parents output -- compiling ./commands/InfoCmd.cc commands/InfoCmd.cc: In member function `virtual void InfoCmd::executeArgs(char*)': commands/InfoCmd.cc:7: no matching function for call to `CommandContext:: getUnit()' make: *** [output/./commands/InfoCmd.o] Error 1
Øyvind, I think what you are seeing is bug 32027.
Independent of Øyvind's observations, this bug still appears in 2.0. We do get markers at the include statements.
PR was targeted to the 2.0 release but not resolved, moving target to 2.1
> Independent of Øyvind's observations, this bug still appears in 2.0. We do get > markers at the include statements. Yes we do and it is intentional. Moving this to 3.0 where we will revisit this scheme
(In reply to comment #11) > > Independent of Øyvind's observations, this bug still appears in 2.0. We do > get > > markers at the include statements. > > Yes we do and it is intentional. > Moving this to 3.0 where we will revisit this scheme > > not high priority, moving to future. But we certainly can do a better job at this
Returning to the pool.
Well, the error parsers have been rewritten and the header files are no longer reported anyway, since they aren't really errors. You can always go back to the build console to get this info.
