[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 142551] goto next error: treat warnings as errors
From:       Maciej Pilichowski <bluedzins () wp ! pl>
Date:       2007-05-25 10:38:01
Message-ID: 20070525103801.14746.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=142551         




------- Additional Comments From bluedzins wp pl  2007-05-25 12:37 -------
David, so I think we can all agree that additional shortcut for jumping to warnings \
is a good thing. Ok with me.

However... :-) Andreas,

> shortcut that says it goes to the next/previous error should only go to the
> next/previous error. Wether you think that any warning is an error is
> irrelevant for this. 

I cannot agree with you -- pure logic, if I set warning=error, gcc runs with it, why \
KDevelop could not accept this fact? With such settings program won't compile if \
there is even single warning. So it is not that I "think" something, I set \
equivalence relation.

> As far as using -Werror goes: That doesn't make gcc output the warnings as
> errors, it just makes gcc stop compilation. 

Andres -- yes, as you said, it does not _output_ them as errors, it _processes_ them \
as errors. I don't ask for anything more: please process in such case warnings as \
errors, the same as gcc does.

My 2 cents to solutions of this:
1) your solution
2) treat warnings (no matter what gcc mode is) as sub-errors; it could goto warning \
only when: 2.a) there were no errors
2.b) after the last error (error1, error2, warning1, error3; F4 -> e1, e2, e3, w1)
3) option in KDevelop regardless gcc, that goto error should include warnings
4) additional shortcut "goto error/warning" (whatever is nearer)
5) allow shortcut double bindings (but I am afraid that kdelibs does not allow this), \
then choose "the real" action depending what (error/warning) is closer

Uff... :-) Personaly I like (3), simplest, and effective. Besides I doubt there are \
so many people who run mixed projects (project A error!=warning, project B \
error=warning).


[prev in list] [next in list] [prev in thread] [next in thread]