Bug 52974 - Canonicalize include paths in diagnostics
Summary: Canonicalize include paths in diagnostics
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2012-04-13 13:14 UTC by Jonathan Wakely
Modified: 2025-02-01 18:30 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-04-15 00:00:00


Attachments
patch (1.08 KB, patch)
2012-04-15 15:31 UTC, Manuel López-Ibáñez
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2012-04-13 13:14:54 UTC
#include <algorithm>
void f() { std::sort(1); }

The diagnostics caused by misuse of the standard library are ridiculous:


t.cc: In function 'void f()':
t.cc:2:23: error: no matching function for call to 'sort(int)'
t.cc:2:23: note: candidates are:
In file included from /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template<class _RAIter> void std::sort(_RAIter, _RAIter)
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5: note:   template argument deduction/substitution failed:
t.cc:2:23: note:   candidate expects 2 arguments, 1 provided
In file included from /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template<class _RAIter, class _Compare> void std::sort(_RAIter, _RAIter, _Compare)
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5: note:   template argument deduction/substitution failed:
t.cc:2:23: note:   candidate expects 3 arguments, 1 provided

Users don't care that the include path is $PREFIX/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0

The paths should be canonicalized using realpath(3) to simply /home/redi/gcc/4.x/include/c++/4.8.0/algorithm and /home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h

This probably isn't a good idea for user headers, as the include path they use with -I should be preserved so they recognise it, but for GCC's own C++ headers (and possibly all system headers?) it would be a huge improvement.
Comment 1 Jonathan Wakely 2012-04-13 13:16:01 UTC
The canonicalized version of that error is a lot more readable

t.cc: In function 'void f()':
t.cc:2:23: error: no matching function for call to 'sort(int)'
t.cc:2:23: note: candidates are:
In file included from /home/redi/gcc/4.x/include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template<class _RAIter> void std::sort(_RAIter, _RAIter)
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5420:5: note:   template argument deduction/substitution failed:
t.cc:2:23: note:   candidate expects 2 arguments, 1 provided
In file included from /home/redi/gcc/4.x/include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template<class _RAIter, class _Compare> void std::sort(_RAIter, _RAIter, _Compare)
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5456:5: note:   template argument deduction/substitution failed:
t.cc:2:23: note:   candidate expects 3 arguments, 1 provided
Comment 2 Manuel López-Ibáñez 2012-04-13 13:42:51 UTC
(In reply to comment #0)
> This probably isn't a good idea for user headers, as the include path they use
> with -I should be preserved so they recognise it, but for GCC's own C++ headers
> (and possibly all system headers?) it would be a huge improvement.

System headers are easy to detect, but what is "GCC's own C++ headers"? How can one detect those?
Comment 3 Jonathan Wakely 2012-04-13 13:55:27 UTC
I don't know where they're defined but they're built in and g++ -v shows them

#include "..." search starts here:
#include <...> search starts here:
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
 /usr/local/include
 /home/redi/gcc/4.x/include
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
 /usr/include
End of search list.

The C++ headers are the only ones that need canonicalizing.
Comment 4 Manuel López-Ibáñez 2012-04-15 15:31:46 UTC
Created attachment 27160 [details]
patch

This patch implements the shortening in line-map.c. It seems more general fix than touching the default include paths.

If it looks ok to you, I will submit it properly.
Comment 5 Jonathan Wakely 2012-04-15 18:32:49 UTC
That was fast :)

I've only tested it lightly but it looks great, thank you very much.
Comment 6 Manuel López-Ibáñez 2012-04-30 17:01:11 UTC
Author: manu
Revision: 186991
Modified property: svn:log

Modified: svn:log at Mon Apr 30 17:00:59 2012
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Mon Apr 30 17:00:59 2012
@@ -1,6 +1,6 @@
 2012-04-30  Manuel López-Ibáñez  <manu@gcc.gnu.org>
 	    Dodji Seketeli  <dodji@seketeli.org>
 
-	PR 5297
+	PR c++/52974
 	* libcpp/files.c (maybe_shorter_path): New.
 	(find_file_in_dir): Use it.
Comment 7 Jonathan Wakely 2012-04-30 17:03:30 UTC
Nice, thanks very much!
Comment 8 Manuel López-Ibáñez 2012-04-30 17:20:19 UTC
(In reply to comment #7)
> Nice, thanks very much!

Does it also help with the debug info? I haven't tested that. 

Also, I don't think it changes the output of g++ -v.
Comment 9 Jonathan Wakely 2012-05-02 23:04:55 UTC
(In reply to comment #8)
> Does it also help with the debug info? I haven't tested that. 

It does, great!
 
> Also, I don't think it changes the output of g++ -v.

It doesn't, I don't care :)

Thanks again.