[Bug c++/14912] New: Do not print default template arguments in error messages

[Bug c++/14912] New: Do not print default template arguments in error messages

[schnetter at aei dot mpg dot de]

Errors or warnings in templated functions often print a ridiculously long type 
name, especially when the STL is involved, as in 
 
/home/eschnett/Calpha/Cactus/configs/einstein-gfortran-debug/build/CarpetRegrid/centre.cc: 
In function `int CarpetRegrid::Centre(constcGH*, constgh<3>&, int, int, int, 
constCarpet::jjvect&, constCarpet::jjvect&, constCarpet::jjvect&, 
constCarpet::jjvect&, 
__gnu_norm::vector<__gnu_norm::vector<__gnu_norm::vector<bbox<int, 3>, 
std::allocator<bbox<int, 3> > >, std::allocator<__gnu_norm::vector<bbox<int, 
3>, std::allocator<bbox<int, 3> > > > >, 
std::allocator<__gnu_norm::vector<__gnu_norm::vector<bbox<int, 3>, 
std::allocator<bbox<int, 3> > >, std::allocator<__gnu_norm::vector<bbox<int, 
3>, std::allocator<bbox<int, 3> > > > > > >&, 
__gnu_norm::vector<__gnu_norm::vector<vect<vect<bool, 2>, 3>, 
std::allocator<vect<vect<bool, 2>, 3> > >, 
std::allocator<__gnu_norm::vector<vect<vect<bool, 2>, 3>, 
std::allocator<vect<vect<bool, 2>, 3> > > > >&, 
__gnu_norm::vector<__gnu_norm::vector<int, std::allocator<int> >, 
std::allocator<__gnu_norm::vector<int, std::allocator<int> > > >&)': 
/home/eschnett/Calpha/Cactus/configs/einstein-gfortran-debug/build/CarpetRegrid/centre.cc:46: 
warning: comparison between signed and unsigned integer expressions 
 
 
 
I never typed in all this "allocator" and "__gnu_norm" stuff.  I assume these 
are default template parameters.  Would it be possible to not print them?  It 
would make the warning message readable. 
 
Oh.  I just see that there is no space after the "const" keywords.  Is that 
intentional?

-- 
           Summary: Do not print default template arguments in error
                    messages
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schnetter at aei dot mpg dot de
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-10 19:39 -------
The no space after the const is a bug, please file a seperate PR for it as it is a regression from 3.4.0.

Note that the allocator template argument is required by the C++ standard.

But other than that I can confirm this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org
           Keywords|                            |diagnostic
            Version|tree-ssa                    |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[schnetter at aei dot mpg dot de]

------- Additional Comments From schnetter at aei dot mpg dot de  2004-04-10 19:51 -------
I do not understand your second statement.  Do you want to say that the C++ 
standard requires default template parameters in diagnostics, or that the STL 
classes have to take these default template parameters?  I would expect the 
latter, but the former would be inconvenient. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-10 19:55 -------
I mean the latter.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-10 19:55:53
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-10 21:49 -------
Subject: Re:  Do not print default template arguments in error messages

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| The no space after the const is a bug, please file a seperate PR for
| it as it is a regression from 3.4.0. 

Yes, it is a bug.  Fixed soon.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
I'll try to do this. This is a simple testcase:

---------------------------
template <class T, int N=0, int X=1>
struct A
{
   typedef typename T::x x;
};
void foo(void)
{
  A<void,0> a;
}
---------------------------
test.cc: At global scope:
test.cc: In instantiation of 'A<void, 0, 1>':
test.cc:8:   instantiated from here
test.cc:4: error: 'void' is not a class, struct, or union type

Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 
should GCC try and remember which arguments were really specified in the 
template-id (hard to do), or a simple check of equalness between the argument 
and the default parameter would suffice?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave at boost-consulting dot
                   |                            |com
         AssignedTo|unassigned at gcc dot gnu   |giovannibajo at libero dot
                   |dot org                     |it
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-23 04:55 -------
"should GCC try and remember which arguments were really specified in the 
template-id (hard to do), or a simple check of equalness between the argument 
and the default parameter would suffice?"

GCC should not try to remember the arguments.  That path is a slippery slope,
and leads to things similar to "deep typedef substitution," which makes error
messages much harder to read than necessary.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 10:51 -------
The first non-trivial issue is that, in order to print "std::vector<int>" 
instead of "std::vector<int, std::allocator<int> >", we need to do the template 
substitution at error printing time, and check if the resulting substitution 
match. Either that, or I need to mark template arguments with a flag if they 
come from the template-id.

Also, should we skip default arguments also in lines like this:

test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
int X = 1]':

We would be left with something like :

test.cc: In member function `void A<T, N, X>::foo() [with T = int]':

I assume that sounds about right, even if it might be surprising at first why 
the "with" clause does not show all the parameters.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 11:01 -------
or maybe:

test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 
<default>, int X = <default>]':


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-23 12:55 -------
Doesn't sound right to me.  

I think you should either show vector<T> or include A in the "with" clause of
vector<T,A>.  I'm sort of inclined to the former; Don't forget that parameter
names are not always so short.  Another related issue is that "with" clauses are
sometimes unhelpful, as in the case you cite.  vector<int> is much, much
clearer.  GCC ought to have a heuristic based on the lengths of the version with
the "with" clause and the version with a full argument substitution, to decide
whether to use "with" or just substitute the arguments in-line.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-24 02:15 -------
(In reply to comment #9)

> Doesn't sound right to me. [...]
> GCC ought to have a heuristic based on the lengths of the version with
> the "with" clause and the version with a full argument substitution, to decide
> whether to use "with" or just substitute the arguments in-line.

I cannot fix all the diagnostic problems in GCC with a single patch, we need to 
do this incrementally. The first patch will deal with just removal of default 
arguments, and I believe that the less intrusive and clean solution is to 
display <default> in the "with" clause.

Your heuristic proposal makes a lot of sense, and we can revisit it when we are 
done with the issue described in this bug.

I'd like also to reverse the instantiation context but that's a different patch 
again.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:06 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
| I'll try to do this. This is a simple testcase:
| 
| ---------------------------
| template <class T, int N=0, int X=1>
| struct A
| {
|    typedef typename T::x x;
| };
| void foo(void)
| {
|   A<void,0> a;
| }
| ---------------------------
| test.cc: At global scope:
| test.cc: In instantiation of 'A<void, 0, 1>':
| test.cc:8:   instantiated from here
| test.cc:4: error: 'void' is not a class, struct, or union type
| 
| Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 

Most of the time, we want to print what user wrote.  In some cases, we
want to have the pretty-printer show all arguments.  I certainly don't
want unconditional omission of default argument.  You will probably
have to work on the '#' modifier -- ideally, a patch tp that effect
should confive cxx-pretty-printer.c and nor error.c.

| should GCC try and remember which arguments were really specified in the 
| template-id (hard to do), or a simple check of equalness between the argument 
| and the default parameter would suffice?


Not necessarily, we don't have unified types system in the C++
front-end.  But, you can use same_type_p().

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:09 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| The first non-trivial issue is that, in order to print "std::vector<int>" 
| instead of "std::vector<int, std::allocator<int> >", we need to do the template 
| substitution at error printing time, and check if the resulting substitution 
| match.

I don't think so.  Look at the way error.c print templates.

 Either that, or I need to mark template arguments with a flag if they 
| come from the template-id.
| 
| Also, should we skip default arguments also in lines like this:
| 
| test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
| int X = 1]':
| 
| We would be left with something like :

Look at the most general template and same_type_p() with any default
type.  Again that is better done with cxx-pretty-print.c

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:09 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 11:01 -------
| or maybe:
| 
| test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 
| <default>, int X = <default>]':

oh no.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:11 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| I cannot fix all the diagnostic problems in GCC with a single patch,
| we need to do this incrementally.

100% agreed.

| The first patch will deal with just removal of default 
| arguments, and I believe that the less intrusive and clean solution is to 
| display <default> in the "with" clause.

please:

  (1) don't do an unconditional removal;
  (2) don't show <default>.

I would oppose any patch short of that.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:30 -------
(In reply to comment #14)

> | The first patch will deal with just removal of default 
> | arguments, and I believe that the less intrusive and clean solution is to 
> | display <default> in the "with" clause.
> please:
>   (1) don't do an unconditional removal;
>   (2) don't show <default>.
> I would oppose any patch short of that.

Yes, the remove will be conditioned on a flag (but I believe this has to become 
the default).

About the <default>, I don't understand what you are proposing as an 
alternative. Are you proposing to completely remove those template parameters 
from the "with" clause? To me it's almost indifferent. I believe the <default> 
is clearer, but I'm not strong on it either, and I am happy to change it if it 
has to be a showstopper for the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:35 -------
(In reply to comment #12)

> Look at the most general template and same_type_p() with any default
> type.  

How can it work? The default parameter can be dependent on previous template 
parameters. For instace, in vector, the default type in the most general 
template would be something like std::allocator<T> (with T being a previous 
template parameter), while the type in the instantiation is something like 
std::allocator<int>.

> Again that is better done with cxx-pretty-print.c

I don't know what cxx-pretty-print.c is, exactly. Is it currently used? 
Everytime I step with GDB into an error()/warning()/info() call I only see code 
from errors.c being used. My current patch is modifying errors.c because that 
is what the FE currently uses, as far as I can tell.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 02:01 -------
Subject: Re:  Do not print default template arguments in error messages

"gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:06 -------
> Subject: Re:  Do not print default template arguments in error messages
>
> "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
> | I'll try to do this. This is a simple testcase:
> | 
> | ---------------------------
> | template <class T, int N=0, int X=1>
> | struct A
> | {
> |    typedef typename T::x x;
> | };
> | void foo(void)
> | {
> |   A<void,0> a;
> | }
> | ---------------------------
> | test.cc: At global scope:
> | test.cc: In instantiation of 'A<void, 0, 1>':
> | test.cc:8:   instantiated from here
> | test.cc:4: error: 'void' is not a class, struct, or union type
> | 
> | Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 
>
> Most of the time, we want to print what user wrote.  

That rule could be really bad in cases like:

     A<void, foo<bar>::value>

The actual identity of the 2nd argument is usually far more important
at the point where the error is reported than seeing the way the user
wrote it, and the deduction needed for the user to determine that
foo<bar>::value is actually 0, 1, or whatever can be arbitrarily
complicated.  The user may have to look through an arbitrary number of
template definitions in arbitrary locations, finding all
specializations and essentially doing instantiation by hand.  By
contrast, finding out how a template argument was written is trivial
because GCC gives you a nice backtrace where you will see each
template in the instantiation chain being supplied with arguments.

Please, I'm begging you not to go down this road.  GCC is one of the
only compilers that gets it right today (VC8 will follow), and all the
ones that try to follow the "show how it was written" rule often give
errors that are, for all practical purposes, unusable.  If you make
GCC work like the others, it will be a leap backwards and a terrible
disservice to users.

If you choose to show an argument that happens to match the default
but was in fact supplied explicitly, I have no real objection.  Just
show it in its simplified normal form and do not try to show "what was
written."

If you never really meant to go in the direction I fear, I just ask
that you try find a way to describe what you want that can't be
misinterpreted the way I did.  Someone might go off and do the wrong
thing anyway unless it is expressed clearly.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:04 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:30 -------
| (In reply to comment #14)
| 
| > | The first patch will deal with just removal of default 
| > | arguments, and I believe that the less intrusive and clean solution is to 
| > | display <default> in the "with" clause.
| > please:
| >   (1) don't do an unconditional removal;
| >   (2) don't show <default>.
| > I would oppose any patch short of that.
| 
| Yes, the remove will be conditioned on a flag (but I believe this has to become 
| the default).

which flag?  A compiler option?  I don't think a multiplication of
compiler options for this stuff is a good way to go.

| About the <default>, I don't understand what you are proposing as an 
| alternative. Are you proposing to completely remove those template parameters 
| from the "with" clause? 

when they are default, yes.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:06 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:35 -------
| (In reply to comment #12)
| 
| > Look at the most general template and same_type_p() with any default
| > type.  
| 
| How can it work? The default parameter can be dependent on previous template 
| parameters. For instace, in vector, the default type in the most general 
| template would be something like std::allocator<T> (with T being a previous 
| template parameter), while the type in the instantiation is something like 
| std::allocator<int>.
| 
| > Again that is better done with cxx-pretty-print.c
| 
| I don't know what cxx-pretty-print.c is, exactly.

cp/cxx-pretty-print.c

| Is it currently used? 

Yes.  Curently, the pretty-printing job is done by both error.c and
cxx-pretty-print.c.  But, the goal is to move the codes to the latter.


| Everytime I step with GDB into an error()/warning()/info() call I only see code 
| from errors.c being used. My current patch is modifying errors.c because that 
| is what the FE currently uses, as far as I can tell.

you're just mistaken.  I have been modifying the codes for long time
now, and I have an idea of the code path.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
Subject: Re:  Do not print default template arguments in error messages

"dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| Please, I'm begging you not to go down this road.  GCC is one of the

I know you have strong opinions on what compilers should print; we had
part of this discussions on -core and it did not seem like that was a
universal solution that handles all the cases.  I'm going to scheme
that handle the majority of the cases right.

| only compilers that gets it right today (VC8 will follow), and all the
| ones that try to follow the "show how it was written" rule often give
| errors that are, for all practical purposes, unusable.  If you make
| GCC work like the others, it will be a leap backwards and a terrible
| disservice to users.

yes, you're entitled to your opinions.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 11:59 -------
Subject: Re:  Do not print default template arguments in error messages

gdr at integrable-solutions dot net <gcc-bugzilla@gcc.gnu.org> wrote:

>>>> The first patch will deal with just removal of default
>>>> arguments, and I believe that the less intrusive and clean
>>>> solution is to
>>>> display <default> in the "with" clause.
>>> please:
>>>   (1) don't do an unconditional removal;
>>>   (2) don't show <default>.
>>> I would oppose any patch short of that.
>>
>> Yes, the remove will be conditioned on a flag (but I believe this
>> has to become
>> the default).
>
> which flag?  A compiler option?  I don't think a multiplication of
> compiler options for this stuff is a good way to go.

Then what? You said "don't do an unconditional removal". What did you mean,
exactly?

Giovanni Bajo



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 12:57 -------
Subject: Re:  Do not print default template arguments in error messages

"gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
> Subject: Re:  Do not print default template arguments in error messages
>
> "dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:
>
> [...]
>
> | Please, I'm begging you not to go down this road.  GCC is one of the
>
> I know you have strong opinions on what compilers should print; we had
> part of this discussions on -core and it did not seem like that was a
> universal solution that handles all the cases.  

First, I don't know if I've misunderstood what you meant by "show how
it was written," so I'd really appreciate if you'd clarify that before
we go any further down this road.  To make it easy on you, let me try
to be very clear about what I fear.  If you run this through the
Comeau on-line compiler:

  template <class T>
  struct foo1
  {
      // ...
      typedef T* pointer; 
  };

  template <class T>
  struct foo2
  {
      // ...
      typedef T** pointer; // oops, should've been T*
  };

  template <class U, class V>
  struct bar
  {
      bar( V v )
      {
          U u = v;
      }
  };

  template <class U, class V>
  struct baz
  {
      baz()
      {
          bar<
              typename foo1<U>::pointer,
              typename foo2<V>::pointer
          > b(0);
      };
  };

  baz<int,int> x;

You'll get a message that says:

  line 20: error: a value of type "foo2<int>::pointer" cannot be
          used to initialize an entity of type "foo1<int>::pointer"
            U u = v;
                  ^
          detected during:
            instantiation of "bar<U, V>::bar(V) [with U=foo1<int>::pointer,
                      V=foo2<int>::pointer]" at line 32
            instantiation of "baz<U, V>::baz() [with U=int, V=int]" at line 36


It is the appearance of "foo1<int>::pointer" and "foo2<int>::pointer"
in the error message, rather than "int*" and "int**", that I'm
concerned about.  Nothing in the error message points at
the definition of foo1 or foo2 above, so the user gets no help in
understanding which one might be the true cause of the error.  And
even if it pointed at foo1 or foo2, in general the real source of
foo2<T>::pointer could easily have been some other template:

  template <class T>
  struct foo1
  {
      typedef typename foobar<T>::value_type* pointer; 
  };

This happens very typically in the standard library, where nested
types are transferred and modified from allocators into containers and
so forth.  I want to be sure that GCC continues to show "int*"
and "int**" in these cases.  

> I'm going to scheme that handle the majority of the cases right.

Assuming your intention is to do what I fear (otherwise, please ignore
the rest):

On what basis can you say that?  Have you got some measurement of what
the majority of cases look like, and an objective way to understand
what "right" is?

No solution universally handles all the cases perfectly, but we can
make some objective analysis of how tractable it is to find any given
piece of important information in the various schemes.  Going down the
EDG path may make a few kinds of analysis incrementally easier, but it
makes other kinds vastly harder, to the point of being nearly
impossible.  I keep a copy of GCC on hand at all times just for
situations like this, no mater what compiler I'm using.  I find it
ironic that if GCC makes the change I fear, the only compiler left
that yields workable error messages in these kinds of situations will
be from Microsoft.

> | only compilers that gets it right today (VC8 will follow), and all
> | the ones that try to follow the "show how it was written" rule
> | often give errors that are, for all practical purposes, unusable.
> | If you make GCC work like the others, it will be a leap backwards
> | and a terrible disservice to users.
>
> yes, you're entitled to your opinions.

This is very disappointing.  Condescencion is entirely uncalled for.
I won't claim to know what your level of expertise is, but I know I've
done more comparative research on template-related error messages than
most people.  If you care about GCC's usability you ought at least to
take what I say seriously.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 15:40 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 11:59 -------
| Subject: Re:  Do not print default template arguments in error messages
| 
| gdr at integrable-solutions dot net <gcc-bugzilla@gcc.gnu.org> wrote:
| 
| >>>> The first patch will deal with just removal of default
| >>>> arguments, and I believe that the less intrusive and clean
| >>>> solution is to
| >>>> display <default> in the "with" clause.
| >>> please:
| >>>   (1) don't do an unconditional removal;
| >>>   (2) don't show <default>.
| >>> I would oppose any patch short of that.
| >>
| >> Yes, the remove will be conditioned on a flag (but I believe this
| >> has to become
| >> the default).
| >
| > which flag?  A compiler option?  I don't think a multiplication of
| > compiler options for this stuff is a good way to go.
| 
| Then what? You said "don't do an unconditional removal". What did you mean,
| exactly?


Use the format flags -- I think I already said that -- '#'.
If it is present (i.e. the verbose parameter non zero, therefore the
flags asking for default values) then honor it.  Otherwise effectively
don't print the default values.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 15:55 -------
Subject: Re:  Do not print default template arguments in error messages

"dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From dave at boost-consulting dot com  2005-03-26 12:57 -------
| Subject: Re:  Do not print default template arguments in error messages
| 
| "gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:
| 
| > ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
| > Subject: Re:  Do not print default template arguments in error messages
| >
| > "dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| >
| > [...]
| >
| > | Please, I'm begging you not to go down this road.  GCC is one of the
| >
| > I know you have strong opinions on what compilers should print; we had
| > part of this discussions on -core and it did not seem like that was a
| > universal solution that handles all the cases.  
| 
| First, I don't know if I've misunderstood what you meant by "show how
| it was written,"

If user writes vector<int>, I would like to print vector<T> [with T = int],
not vector<int>, <default> > (or variants).  Similarly, if user
wirtes vector<int, allocator<int> >, then ideally I would also like to
print vector<T, Allocator> [with T = int, Allocator = alloctor<int>].

There are discussions about carret diagnostics, but this is not it.

[...]

| > I'm going to scheme that handle the majority of the cases right.
| 
| Assuming your intention is to do what I fear (otherwise, please ignore
| the rest):

I can't ignore ignore the rest, not because I'm goiing to do something
stupid but because you also request to tke what you're saying
"seriously".  And also, because, I'm a bit fed up of your arrogance.

[...]

| > | only compilers that gets it right today (VC8 will follow), and all
| > | the ones that try to follow the "show how it was written" rule
| > | often give errors that are, for all practical purposes, unusable.
| > | If you make GCC work like the others, it will be a leap backwards
| > | and a terrible disservice to users.
| >
| > yes, you're entitled to your opinions.
| 
| This is very disappointing.  Condescencion is entirely uncalled for.

oh really?  when people try to do things, you immediately think or
"fear" that they are going to do the wrong thing.  Oh yeah, that is
not called "condescencion", you're just feeling they are stupid.

| I won't claim to know what your level of expertise is, but I know I've
| done more comparative research on template-related error messages than
| most people.  If you care about GCC's usability you ought at least to
| take what I say seriously.

Oh, I do read what you write -- everytime I have the chance.  
I know also from experience usually it is probably good not to say
anything contrary to your opinions.  But I can't resist, especially
when you don't quite understand the variations. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 16:14 -------
This is obviously becoming personal.  I wanted a record of my technical concerns
in the bug database, but as the tone has changed I don't think it's appropriate
to continue this here.  I will reply to Gaby offline and try to clear up the
misunderstandings there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:24 -------
OK, before I clean up the patch, I'll post an example. For this code:

----------------------------------------------
#include <map>
#include <vector>
#include <string>

std::map<std::string, std::vector<int> > m;

void bar(void)
{
  std::vector<int> k;
  m.insert(std::make_pair(0, k));
}
----------------------------------------------

I get this:

<path>/stl_pair.h: In constructor 'std::pair<_T1, _T2>::pair(const 
std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int>, _T1 = const 
std::string, _T2 = std::vector<int>]':
test3.cc:10:   instantiated from here
<path>/stl_pair.h:90: error: invalid conversion from 'const int' to 'const 
char*'
<path>/stl_pair.h:90: error:   initializing argument 1 
of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, 
const _Alloc&) [with _CharT = char]'

(I manually edited '<path>')
Without my patch, I get this:


<path>/stl_pair.h: In constructor `std::pair<_T1, _T2>::pair(const 
std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int, 
std::allocator<int> >, _T1 = const std::string, _T2 = std::vector<int, 
std::allocator<int> >]':
test3.cc:10:   instantiated from here
<path>/stl_pair.h:90: error: invalid conversion from `const int' to `const 
char*'
<path>/stl_pair.h:90: error:   initializing argument 1 of 
`std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const 
_Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>]'


If someone wants to submit an additional testcase, I'm happy to test it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:26 -------
Another comparison:

---------------------------------------
#include <vector>

template <class T, int N=0, int X=1>
struct A
{
  std::vector<T> v;
  
  void foo(void)
  { v.doesnotexist(); }
};

void foo(void)
{
  A<int,0> a;
  a.foo();
}
---------------------------------------

Patched:
test.cc: In member function 'void A<T, N, X>::foo() [with T = int]':
test.cc:14:   instantiated from here
test.cc:9: error: 'class std::vector<int>' has no member named 'doesnotexist'


Unpatched:
test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
int X = 1]':
test.cc:14:   instantiated from here
test.cc:9: error: 'class std::vector<int, std::allocator<int> >' has no member 
named 'doesnotexist'



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 19:52 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:24 -------
| OK, before I clean up the patch, I'll post an example. For this code:
| 
| ----------------------------------------------
| #include <map>
| #include <vector>
| #include <string>
| 
| std::map<std::string, std::vector<int> > m;
| 
| void bar(void)
| {
|   std::vector<int> k;
|   m.insert(std::make_pair(0, k));
| }
| ----------------------------------------------
| 
| I get this:
| 
| <path>/stl_pair.h: In constructor 'std::pair<_T1, _T2>::pair(const 
| std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int>, _T1 = const 
| std::string, _T2 = std::vector<int>]':
| test3.cc:10:   instantiated from here
| <path>/stl_pair.h:90: error: invalid conversion from 'const int' to 'const 
| char*'
| <path>/stl_pair.h:90: error:   initializing argument 1 
| of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, 
| const _Alloc&) [with _CharT = char]'
| 
| (I manually edited '<path>')
| Without my patch, I get this:

That is  fair improvement.  I realize we don't retain std::string in
the last diagnostic, but we don't need to do that before you check-in
your patch -- that is a whole project in itself.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-03-26 22:57 -------
Giovanni, in your example in comment #27, you get this: 
 
>Patched: 
>test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
>test.cc:14:   instantiated from here 
>test.cc:9: error: 'class std::vector<int>' has no member named 'doesnotexist' 
 
That's a good improvement, but do you think you could write the first line 
with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
third template argument, but then no explanation as to their values... 
 
Thanks 
  Wolfgang 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-27 00:56 -------
(In reply to comment #31)

> >Patched: 
> >test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
> >test.cc:14:   instantiated from here 
> >test.cc:9: error: 'class std::vector<int>' has no member 
named 'doesnotexist' 
>  
> That's a good improvement, but do you think you could write the first line 
> with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
> third template argument, but then no explanation as to their values... 

That's exactly what I was hinting at at the end of comment #7. I then 
implemented the solution proposed in comment #8 (showing them with <default>), 
until Gaby said it would be a showstopper.

I will investigate printing A<T> instead of A<T,N,X>, but I am not confident it 
can be done easily (if at all).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-27 01:52 -------
This is obviously becoming personal.  I wanted a record of my technical concerns
in the bug database, but as the tone has changed I don't think it's appropriate
to continue this here.  I will reply to Gaby offline and try to clear up the
misunderstandings there.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dave at boost-consulting dot|
                   |com                         |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-27 03:16 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #31)
| 
| > >Patched: 
| > >test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
| > >test.cc:14:   instantiated from here 
| > >test.cc:9: error: 'class std::vector<int>' has no member 
| named 'doesnotexist' 
| >  
| > That's a good improvement, but do you think you could write the first line 
| > with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
| > third template argument, but then no explanation as to their values... 
| 
| That's exactly what I was hinting at at the end of comment #7. I then 
| implemented the solution proposed in comment #8 (showing them with <default>), 
| until Gaby said it would be a showstopper.

*If* you print N and X then yes it is surprising not to say what they
 bind to ("explanation"); but "<default>" is not good.
However, if you do not print them, then you don't have to explain what
 they mean.

| I will investigate printing A<T> instead of A<T,N,X>, but I am not confident it 
| can be done easily (if at all).

If you're going to print only the binding of "T", and not for N nor
X, then you do know that you don't have to print them, i.e. they are
instantiated with default values.
Granted, as the code in error.c currently is, you would have those
information only after the fact (in dump_bindings()).  However, the
code path in cxx-pretty-print.c is different and more amenable to that
kind of thing.  Alternatively, you could do lazy printing with error.c
but that is more complicated than it should be.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912