OK.
Jason
New version of the patch. Bootstrapped and regression tested.
Is this version OK?
2012-04-29 Manuel López-Ibáñez m...@gcc.gnu.org
Dodji Seketeli do...@seketeli.org
PR 5297
* libcpp/files.c (maybe_shorter_path): New.
(find_file_in_dir): Use it.
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
PR 5297
* libcpp/files.c (maybe_shorter_path): New.
(find_file_in_dir): Use it.
I can't approve or deny this patch, but for what it's worth, I find it
fine.
Thanks.
--
Dodji
On 26 April 2012 12:12, Dodji Seketeli do...@seketeli.org wrote:
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
On 21 April 2012 14:56, Jason Merrill ja...@redhat.com wrote:
It seems like we'll do this for every line in the header, which could lead
to a lot of leaked memory. Instead, we
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Another drawback I didn't realize until now is that in this way the
canonicalize every path, instead of only touching those that belong to
system headers.
Ah. Good catch.
I guess file-dir-sysp should tell us if we are in a system directory,
Jason Merrill ja...@redhat.com a écrit:
It seems like we'll do this for every line in the header, which could
lead to a lot of leaked memory. Instead, we should canonicalize when
setting ORDINARY_MAP_FILE_NAME.
[...]
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
On 21 April 2012
On 26 April 2012 11:12, Dodji Seketeli wrote:
So maybe it'd be better to canonicalize the _cpp_file::path when it's
first build? One drawback of that approach would be that
_cpp_file::path will then permanently loose the information about the
current directory, that is indirectly encoded
On 26 April 2012 12:12, Dodji Seketeli do...@seketeli.org wrote:
So maybe it'd be better to canonicalize the _cpp_file::path when it's
first build? One drawback of that approach would be that
_cpp_file::path will then permanently loose the information about the
current directory, that is
Jonathan Wakely jwakely@gmail.com a écrit:
On 26 April 2012 11:12, Dodji Seketeli wrote:
So maybe it'd be better to canonicalize the _cpp_file::path when it's
first build? One drawback of that approach would be that
_cpp_file::path will then permanently loose the information about the
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Why not remove this comment and free file here with XDELETEVEC (file) ?
+ canonical_path = maybe_shorter_path (path);
+ if (canonical_path != NULL canonical_path != path)
+ {
+ /* The canonical path was newly allocated. Let's
On 26 April 2012 20:11, Dodji Seketeli do...@seketeli.org wrote:
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Why not remove this comment and free file here with XDELETEVEC (file) ?
+ canonical_path = maybe_shorter_path (path);
+ if (canonical_path != NULL canonical_path != path)
+
On 26 April 2012 20:56, Dodji Seketeli do...@seketeli.org wrote:
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
On 26 April 2012 20:11, Dodji Seketeli do...@seketeli.org wrote:
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Why not remove this comment and free file here with
Ping: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00903.html
On 15 April 2012 20:44, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
This patch tries to store the shortest form of a path to a system
file, either the original given or the canonical form returned by
realpath. User files are
I think this patch is a *huge* improvement for C++ diagnostics that
refer to standard library files, I really hope it will be approved in
some form.
On 21 April 2012 12:58, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
Ping: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00903.html
On 15
It seems like we'll do this for every line in the header, which could
lead to a lot of leaked memory. Instead, we should canonicalize when
setting ORDINARY_MAP_FILE_NAME.
Jason
On 21 April 2012 14:56, Jason Merrill ja...@redhat.com wrote:
It seems like we'll do this for every line in the header, which could lead
to a lot of leaked memory. Instead, we should canonicalize when setting
ORDINARY_MAP_FILE_NAME.
Hum, my understanding of the code is that this is exactly
This patch tries to store the shortest form of a path to a system
file, either the original given or the canonical form returned by
realpath. User files are left untouched. This converts this:
t.cc: In function 'void f()':
t.cc:2:23: error: no matching function for call to 'sort(int)'
t.cc:2:23:
17 matches
Mail list logo
