Bug 308846 - Clicking on black messages with file references in build output does not move the cursor to that location.
Summary: Clicking on black messages with file references in build output does not move...
Alias: None
Product: kdevelop
Classification: Unclassified
Component: Output Views (show other bugs)
Version: git master
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: 4.3.0
Assignee: kdevelop-bugs-null
Depends on:
Reported: 2012-10-23 04:56 UTC by Jeremy W. Murphy
Modified: 2012-12-15 03:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy W. Murphy 2012-10-23 04:56:10 UTC
As we are all familiar with, clicking on a yellow warning or red error in the build output moves the cursor to that location.  Usually the same thing works for black link errors and the cascade of "In function 'void foo()': that precede the actual warning/error.  The cursor redirection is no longer working for black messages, which is a regression since 4.3.1.

Reproducible: Always

Steps to Reproduce:
1. Compile anything that produces a warning/error.
2. Click on some black message text that refers to a file.

Actual Results:  

Expected Results:  
Move cursor to most relevant location in that file: variable, function, etc.

dev-util/kdevelop-9999 was built with the following:
USE="cmake (consolekit) cxx (multilib) okteta (policykit) (-aqua) -debug -qthelp -test"
CFLAGS="-march=native -O2 -g -pipe -w"
CXXFLAGS="-march=native -O2 -g -pipe -w"
Comment 1 Jeremy W. Murphy 2012-10-27 07:28:10 UTC
So I tracked it down to here.  Do you want the git bisect log too?

85a93d6e0b7bd64cd9c366b933c64f5365bc2b9c is the first bad commit
commit 85a93d6e0b7bd64cd9c366b933c64f5365bc2b9c
Author: Morten Danielsen Volden <mvolden2@gmail.com>
Date:   Mon Jun 18 21:04:35 2012 +0200

    Use the filtering capabilities of outputview's outputmodel.

:040000 040000 5d9a3190ff49e8e0a8ccf79c1962d3bfa68001fc 51dab8739d9b200811c6c46a2e3e4c3346d0b655 M        projectbuilders
Comment 2 Jeremy W. Murphy 2012-10-28 05:15:05 UTC
Btw, any opinion on whether this is actually a bug or an intentional change in behaviour?
Comment 3 Milian Wolff 2012-11-24 17:40:22 UTC
Git commit b6ca08773255ea685bd0ef1789221cfeebc1f670 by Milian Wolff, on behalf of Morten Danielsen Volden.
Committed on 24/11/2012 at 18:38.
Pushed by mwolff into branch 'master'.

Fix regression in output filtering and improve the output

The patch addresses two things:

a) Fix regression introduced after refactoring outputfiltering
   - It was not possible to click on linker errors
b) Now indicates the linker errors as errors making it visible to
   the user that he can click on them

Also a corrected one of the regular expressions so that it now hits
on all line instances it is supposed to hit on (Come to think of it,
thats three things :-) )

REVIEW: 107446

M  +17   -9    outputview/outputfilteringstrategies.cpp
M  +10   -6    outputview/tests/filteringstrategytest.cpp
M  +5    -0    outputview/tests/testlinebuilderfunctions.h

Comment 4 Jeremy W. Murphy 2012-11-30 00:07:38 UTC
Thanks so much to Morten for fixing the main issue and improving the interface.  However, there is a small but important detail still unresolved: the black text that is not an error but is more useful to click on than the error.  Let me give you a short example:

/home/jeremy/projects/setvspq/main.cpp:130:14:   instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_deque.h:520:53: error: no matching function for call to blah blah blah...

In this example, the first line of text would be black and the second line red.  However, it is almost certainly the case that the user wants to go to where the error was instantiated (in their own code), not to the STL header file for a deque.

Previously, this did work: clicking on the black text above the error would jump to main.cpp:130:14, and it was awesome!  So I guess I am asking that ALL text that references a file:row:column work in the same way as warnings and errors.  Thanks!
Comment 5 Jeremy W. Murphy 2012-12-15 03:26:36 UTC
Fixed, thanks!