Re: Request for a compiler feature

Re: Request for a compiler feature

[Ross Smith]

From: Joe Buck <jbuck@synopsys.com>
>
>Warning: while 95% of the time, outputting the typedef types will be a
big
>improvement, there are a number of errors that the user will have
>difficulty resolving without seeing the expanded types.  These are
cases
>where the error is that a typedef is set to the wrong value; in this
case
>the true error will be hidden.  These types of errors are likely to
occur
>for people developing STL-compatible containers, or for some uses of
such
>containers.
>
>Example: I might accidentally write something like
>
>typedef pair<Key,const Value> MyMapType;
>
>and then later try to use this in conjunction with a map<Key,Value> --
the
>error is that Key should be const and Value non-const.  If I then get
>a bunch of errors about its use, it might take a bit of code-reading to
>track down the error (though maybe that code reading wouldn't be too
>difficult).

Suggestion: Emit the typedefs separately from the main error message.
Something like this:

  foo.cpp:123: Error: MyMapType and MyOtherMapType are incompatible
  foo.cpp:123: MyMapType is typedef for std::pair<Key, const Value>
  foo.cpp:123: MyOtherMapType is typedef for std::pair<Key, Value>

That gives you the clearer error messages in the common cases where the
types involved are complicated template instantiations (e.g.
std::string) but the details aren't relevant, but if you need to you can
still check that the types are what you thought they were.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
  "Remember when we told you there was no future? Well, this is it."
                                                        -- Blank Reg

Re: Request for a compiler feature

[Andi Kleen]

"Ross Smith" <ross.s@ihug.co.nz> writes:

> Suggestion: Emit the typedefs separately from the main error message.
> Something like this:
> 
>   foo.cpp:123: Error: MyMapType and MyOtherMapType are incompatible
>   foo.cpp:123: MyMapType is typedef for std::pair<Key, const Value>
>   foo.cpp:123: MyOtherMapType is typedef for std::pair<Key, Value>
> 
> That gives you the clearer error messages in the common cases where the
> types involved are complicated template instantiations (e.g.
> std::string) but the details aren't relevant, but if you need to you can
> still check that the types are what you thought they were.

That would still confuse the error message listing a lot, because STL
typedefs are often over several lines. I think this case is special enough
that it could be turned on by a separate switch, with the default to off. 
To make it clear gcc could tell the user about it on the first encounter
of a typedef in a message. 

foo.cpp:123: Error: MyMapType and MyOtherMapType are incompatible
foo.cpp:123: Typedef not expanded, use -Wexpand-typedef to change. 

A -W prefix is not really 100% right, but seems to be the best option 
here. 


-A.

Re: Request for a compiler feature

[Joe Buck]

> >> I'd like the compiler to generate error messages based on the typedefs
> >> used in the code, not the actual underlying types.
> 
> > This is a good request.  When we get a little time, I'm sure someone
> > will get it implemented.
> 
> A good start would be checking all the uses of TYPE_MAIN_DECL.  Now that
> typedef types refer to the typedef, we shouldn't throw that information
> away by using TYPE_MAIN_DECL; we should grab the typedef instead in most
> cases.

Sounds good, but:

Warning: while 95% of the time, outputting the typedef types will be a big
improvement, there are a number of errors that the user will have
difficulty resolving without seeing the expanded types.  These are cases
where the error is that a typedef is set to the wrong value; in this case
the true error will be hidden.  These types of errors are likely to occur
for people developing STL-compatible containers, or for some uses of such
containers.

Example: I might accidentally write something like

typedef pair<Key,const Value> MyMapType;

and then later try to use this in conjunction with a map<Key,Value> -- the
error is that Key should be const and Value non-const.  If I then get
a bunch of errors about its use, it might take a bit of code-reading to
track down the error (though maybe that code reading wouldn't be too
difficult).

I hate to propose yet another flag, but at least on a temporary basis, if
this is done, I suggest a flag that would cause errors to be output the
"old" way, with the default being to output the typedef types.

Re: Request for a compiler feature

[Jason Merrill]

>>>>> Mike Stump <mrs@wrs.com> writes:

>> From: Dave Steffen <steffend@glitch.physics.colostate.edu>
>> To: egcs@cygnus.com
>> Date: Tue, 16 Jun 1998 12:15:14 MDT

>> I'd like the compiler to generate error messages based on the typedefs
>> used in the code, not the actual underlying types.

> This is a good request.  When we get a little time, I'm sure someone
> will get it implemented.

A good start would be checking all the uses of TYPE_MAIN_DECL.  Now that
typedef types refer to the typedef, we shouldn't throw that information
away by using TYPE_MAIN_DECL; we should grab the typedef instead in most
cases.

Jason

Re: Request for a compiler feature

[Mike Stump]

> From: Dave Steffen <steffend@glitch.physics.colostate.edu>
> To: egcs@cygnus.com
> Date: Tue, 16 Jun 1998 12:15:14 MDT

> I'd like the compiler to generate error messages based on the typedefs
> used in the code, not the actual underlying types.

This is a good request.  When we get a little time, I'm sure someone
will get it implemented.

Request for a compiler feature

[Dave Steffen]

Howdy,

	I have a request for the Compiler Gods (he says, bowing low):
I'd like the compiler to generate error messages based on the typedefs
used in the code, not the actual underlying types.

	I pointed out last week that normal use of the STL plus a
programming mistake can lead to horrendous error messages, because the
types involved are templates of templates of templates. When the
problem code is inside a function that takes two or three of these
things as arguments, the error message can be 7 or 8 lines long.

        Of course, this is normal behavior in C++; the standard library
is built on templates. But it's still annoying.

       I agree that we've all got higher priorities - I'm waiting for
namespaces and template member functions, myself - it seems to me that
this would be a useful behavior to build into EGCS at some point.

       I don't know squat about how compilers work (I'm just a physics
student trying to debug my code); is it feasable to do this?

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
							- Peart / RUSH
"The reason that our people suffer in this way.... 
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi