Re: [boost] [RFC] Better error messages for errors detected at co mpile time

From: Emily Winch (Emily.Winch_at_[hidden])
Date: 2002-03-26 08:41:20

> I'm proposing a compiler-supported library so that library designers 
> can create the error messages themselves (and not generate the ugly 
> errors in the first place). STLfilt works by cleaning up messy 
> typenames (e.g., look at how a compiler turns std::map into an 
> unreadable mess) after the compiler has executed.
>
> Simple summary: STLfilt works right now, and doesn't change the 
> language but what I'm proposing can help make much nicer error 
> messages.

I think compiler support for decent error messages is pretty much 
essential for usability of template metaprograms. Nevertheless, for the
authors of those programs, a straightforward stack trace of the metaprogram
is necessary. In some circumstances the user might also want their own stack
trace:

foo.cpp(line 4): library author says you can't instantiate a widget with a
woozum

in instantiation of user_code<a, b> at line 9, with a =
library_type_with_a_name_several_pages_long and b = oh_dear_not_another_one

in instantiation of other_user_code<c, d> at ... bla bla

At this point it's difficult to avoid error messages full of extremely long
type names, which the compiler can't simplify without knowledge of the type
itself and how to simplify it. (By simplify, I'm thinking of things like
reducing

some_type<foo, bar, my_namespace::null_type, my_namespace::null_type,
my_namespace::null_type, my_namespace::null_type, my_namespace::null_type,
my_namespace::null_type>

to

some_type<foo, bar>

for example, and all the things that STLfilt does)

For me at the moment, the best solution is piping my compiler output through
a sed script. It would be really really neat to have support from STLfilt
for using custom scripts as well as the STL filtering script. (STLfilt knows
how to hook into Visual Studio and filter the output of that). I talked to
Leor Zolman about that, and he sounded interested in looking into it at some
point. Pretty important is the ability for the user to turn the filtering
_off_ on a per-library basis, because it hides information that they might
at some point need to know. (I'm sure I'm not the only person who
occasionally ends up debugging my own code by delving into the innards of
the library I'm using). I can't imagine this level of error message support
coming from a compiler.

Simple summary: Compiler supported error messages _and_ STLfilt (or
<whatever>filt), please!

Emily