Community
Participate
Working Groups
Eclipse Build ID: M20080911-1700 CDT Version: 5.0.2.200811280802 Build id: 200811280802 Steps To Reproduce: 1. Create a C++ makefile project 2. Create a makefile 3. Create the following target in the makefile: all: @echo 'foo.cc:11:20: error: value with length 0 violates the length restriction: length (1 .. infinity)' 4. Build. There will be a marker with the following text: length(1 .. infinity) The marker text should be: value with length 0 violates the length restriction: length (1 .. infinity) More information: The parser uses the last ':' as the point where the marker text is begins. It should use the first ':' after 'error' or 'warning'.
Created attachment 144730 [details] proposed patch this should now grab the rest of the line after the warning: or error: in the last segment.
Created attachment 145848 [details] updated fix to proposed patch Previous fix missed patters without 'error:' or 'warning:' such as: ..\src\lalaApplication.cpp:33: ';' expected ..\src\lalaApplication.cpp:34: expression syntax error These will default to being errors now.
(In reply to comment #2) > Created an attachment (id=145848) > GCCErrorParser_Warnings=(.*?):([0-9]+):([0-9]+:)?( (.*[Ww]arning:|WARNING:|[Ee]rror:))? (.*) What is the significance of ".*" in expression ".*[Ww]arning:"? It seems to be applied only there and not to "WARNING:" or "[Ee]rror:" contrary to original expression. I think that here not greedy ".*" but reluctant quantifiers ".*?" should be used. It also seems that "[Ee]rror:" is redundant as it will generate errors anyway. However I suggest still keep it as it makes the intention more clear.
Created attachment 147052 [details] alternative patch So I suggest slightly different: > -GCCErrorParser_Warnings=(.*?):([0-9]+):([0-9]+:)?(.*[([Ww]arning)(WARNING)([Ee]rror)]:)? (.*) > +GCCErrorParser_Warnings=(.*?):([0-9]+):([0-9]+:)?(.*?[([Ww]arning)(WARNING)([Ee]rror)]:)? (.*) Seems to resolve the issue.
Since there is no response committing the change with reluctant qualifier. Fixed on HEAD and 6.0.1. Thanks for bringing attention to the bug and suggested patch.
(In reply to comment #5) > Since there is no response committing the change with reluctant qualifier. > Fixed on HEAD and 6.0.1. Thanks for bringing attention to the bug and suggested > patch. Hi Andrew, Sorry for lack of comments. I seem to have lost your original query in my inbox. The .* was just to make sure to get read of any leading chars before the match on the warning patterns. I tried to use alternation (|) to make the expression more readable. Having "[Ee]rror)" is redundant, but I left it for the same reason as you. I ran all our local GCC error regressions against your fix and they all pass so we'll go with your patch now. Thanks for looking into this.
Milestone corrected to 6.0.2 as it was committed there and not in 6.0.1.
I thought a test case for this would be useful, reopening to add one.
Test case added
Tim, is it possible for you to run your local GCC error regressions against the new changes? I would appreciate that. Here is what I did: I converted GCC error parser to RegexErrorParser style which lets a user to tweak patterns in Preferences. The pattern "(.*?):([0-9]+):([0-9]+:)?(.*?[([Ww]arning)(WARNING)([Ee]rror)]:)? (.*)" was real wacky and did not really do what was intended. I split it to pieces. Also, I adjusted the patterns quite a bit to accommodate bug 193982, bug 216443, bug 248669 and to suite my taste. I added a few more test cases and the cases covered by CDT test suite pass. However there is a chance that it broke something. Committed on HEAD (7.0).
(In reply to comment #10) > Tim, is it possible for you to run your local GCC error regressions against the > new changes? > Yes, I'll try to get to it in the new couple of days.
