[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #53 from jason at gcc dot gnu dot org 2009-07-29 20:36 --- Subject: Bug 14912 Author: jason Date: Wed Jul 29 20:35:40 2009 New Revision: 150223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150223 Log: PR c++/14912 * cp-tree.h (enum tsubst_flags): Add tf_no_class_instantiations. * error.c (count_non_default_template_args): Pass it. * pt.c (tsubst) [TYPENAME_TYPE]: Don't complete type if it's set. Added: trunk/gcc/testsuite/g++.dg/template/defarg13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #54 from jason at gcc dot gnu dot org 2009-07-29 21:09 --- Thanks for the testcase, the patch I just checked in should fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #52 from arekm at pld-linux dot org 2009-07-26 10:38 --- btw. this patch backported to gcc 4.4 [1] causes build problems with -g flags like: https://svn.boost.org/trac/boost/ticket/3287 I just tested gcc trunk and the problem is the same. How to test? On linux x86_64 (it's 4MB preprocessed source so won't work on other architectures) do: wget http://carme.pld-linux.org/~arekm/gcc-pr14912.cxx [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/users/arekm/gcc-test --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20090726 (experimental) (GCC) [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -c gcc-pr14912.cxx /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp: In constructor âPluginRegistry::PluginRegistry()â: /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:157:172: internal compiler error: in create_tmp_var, at gimplify.c:504 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. zsh: exit 1 ~/gcc-test/bin/g++ -c gcc-pr14912.cxx So looks ok (beside internal compiler error which is not interesting for us in this case). But now look what happens if -g2 is used: [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -g2 -c gcc-pr14912.cxx In file included from /usr/include/boost/graph/adjacency_list.hpp:39:0, from /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:39: /usr/include/boost/graph/graph_traits.hpp: In instantiation of âboost::graph_traitsboost::adjacency_list â: /usr/include/boost/graph/adjacency_iterator.hpp:53:3: instantiated from âboost::adjacency_iterator_generatorboost::adjacency_list, long unsigned int, boost::detail::out_edge_iter__gnu_cxx::__normal_iteratorboost::detail::sep_long unsigned int, boost::no_property*, std::vectorboost::detail::sep_long unsigned int, boost::no_property , long unsigned int, boost::detail::edge_desc_implboost::directed_tag, long unsigned int, long int â /usr/include/boost/graph/detail/adjacency_list.hpp:2346:56: instantiated from âboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::configâ /usr/include/boost/graph/detail/adjacency_list.hpp:516:7: instantiated from âboost::directed_edges_helperboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::configâ /usr/include/boost/graph/detail/adjacency_list.hpp:568:46: instantiated from âboost::directed_graph_helperboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::configâ /usr/include/boost/graph/detail/adjacency_list.hpp:1489:5: instantiated from âboost::adj_list_helperboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::config, boost::directed_graph_helperboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::config â /usr/include/boost/graph/detail/adjacency_list.hpp:2069:5: instantiated from âboost::vec_adj_list_implboost::adjacency_list, boost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::config, boost::directed_graph_helperboost::detail::adj_list_genboost::adjacency_list, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS::config â /usr/include/boost/graph/adjacency_list.hpp:380:3: instantiated from âboost::adjacency_listâ /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:184:38: instantiated from here /usr/include/boost/graph/graph_traits.hpp:29:47: error: no type named âvertex_descriptorâ in âclass boost::adjacency_listâ /usr/include/boost/graph/graph_traits.hpp:30:45: error: no type named âedge_descriptorâ in âclass boost::adjacency_listâ /usr/include/boost/graph/graph_traits.hpp:31:48: error: no type named âadjacency_iteratorâ in âclass boost::adjacency_listâ /usr/include/boost/graph/graph_traits.hpp:32:47: error: no type named âout_edge_iteratorâ in âclass
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #51 from jason at gcc dot gnu dot org 2009-04-09 20:30 --- Patch applied for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #49 from jason at gcc dot gnu dot org 2009-04-05 06:06 --- I think it's best to just leave the default arguments in when pretty-printing a function template specialization, as in the string example; otherwise we won't know what _Alloc in the function parameter list means. Just omitting default arguments when dumping class template specializations will solve the combinatorial explosion problem as displayed in the original bug report; if we're dealing with vectorvectorvectorint a bug report referring to a member of vector will look like .../libstdc++-v3/include/bits/stl_vector.h:1006: instantiated from void std::vector_Tp, _Alloc::_M_initialize_dispatch(_InputIterator, _InputIterator, std::__false_type) [with _InputIterator = double, _Tp = std::vectorstd::vectorint , _Alloc = std::allocatorstd::vectorstd::vectorint ] So we only see std::allocator once, not in all the sub-vectors. This seems to me like the right balance, which happens to be what the current patch provides. I'm going to clean it up a bit more and check it in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #50 from jason at gcc dot gnu dot org 2009-04-05 19:29 --- Subject: Bug 14912 Author: jason Date: Sun Apr 5 19:29:02 2009 New Revision: 145566 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145566 Log: PR c++/14912 * error.c (count_non_default_template_args): New fn. (dump_template_parms): Call it. (dump_template_argument_list): Call it. Add parms parm. (dump_template_argument): Adjust call to dump_template_argument_list. (dump_type, dump_decl): Likewise. (dump_template_bindings): Refactor logic. Added: trunk/gcc/testsuite/g++.dg/template/error39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #48 from pluto at agmk dot net 2009-03-23 19:00 --- with the latest patch applied on top of 4.4-svn i get following diagnostic for simple code snippet: $ cat 14912-2.cpp #include string std::string s = 7; $ /opt/gcc44/bin/g++ -c -Wall -O2 14912-2.cpp 14912-2.cpp:2: error: invalid conversion from 'int' to 'const char*' 14912-2.cpp:2: error: initializing argument 1 of 'std::basic_string_CharT, _Traits, _Alloc::basic_string(const _CharT*, const _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' defaults are still printed in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #47 from jason at gcc dot gnu dot org 2009-03-03 18:55 --- Created an attachment (id=17392) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17392action=view) updated patch that fixes ICE Here's an update of the patch that fixes the ICE; we need to set processing_template_decl around the call to tsubst_copy_and_build. -- jason at gcc dot gnu dot org changed: What|Removed |Added Attachment #8457 is|0 |1 obsolete|| Attachment #16380|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #45 from pluto at agmk dot net 2009-03-02 21:04 --- bug ping... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #46 from hjl dot tools at gmail dot com 2009-03-02 21:59 --- (In reply to comment #42) Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) [edit] internal-error-testcase I got gnu-6:pts/4[294] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x gnu-6:pts/4[295] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x -O gnu-6:pts/4[296] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x -O2 with gcc 4.4 revision 144547. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #44 from pluto at agmk dot net 2008-09-25 13:20 ---
i can reproduce this internal error on both 4.3.1 and 4.3-head.
here's a backtrace:
Breakpoint 1, error_recursion (context=0x10aeb40) at
../../gcc-4_3-branch/gcc/diagnostic.c:637
637 if (context-lock 3)
(gdb) p *context
$1 = {
printer = 0x112dc10,
diagnostic_count = {0,
0,
0,
2,
0,
0,
0,
0,
0,
0},
issue_warnings_are_errors_message = 1 '\001',
warning_as_error_requested = 0 '\0',
classify_diagnostic = '\0' repeats 764 times,
show_option_requested = 0 '\0',
abort_on_error = 0 '\0',
begin_diagnostic = 0x471f0c cp_diagnostic_starter,
end_diagnostic = 0x471f55 cp_diagnostic_finalizer,
internal_error = 0,
last_function = 0x0,
last_module = 0,
lock = 2
}
(gdb) bt
#0 error_recursion (context=0x10aeb40) at
../../gcc-4_3-branch/gcc/diagnostic.c:637
#1 0x005bbf84 in diagnostic_report_diagnostic (context=0x10aeb40,
diagnostic=0x7fff28b41dd0)
at ../../gcc-4_3-branch/gcc/diagnostic.c:363
#2 0x005bcc7a in internal_error (gmsgid=0xc2a3e7 in %s, at %s:%d) at
../../gcc-4_3-branch/gcc/diagnostic.c:606
#3 0x005bcdfe in fancy_abort (file=0xbe1418
../../gcc-4_3-branch/gcc/cp/pt.c, line=15585, function=0xbe60f0
dependent_type_p)
at ../../gcc-4_3-branch/gcc/diagnostic.c:660
#4 0x00452025 in dependent_type_p (type=0x7fa41a45acc0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15585
#5 0x00495f83 in cxx_sizeof_or_alignof_type (type=0x7fa41a45acc0,
op=250, complain=1 '\001')
at ../../gcc-4_3-branch/gcc/cp/typeck.c:1289
#6 0x00447db8 in tsubst_copy_and_build (t=0x7fa41a443b80,
args=0x7fa41a459b40, complain=tf_none, in_decl=0x0, function_p=0 '\0',
integral_constant_expression_p=1 '\001') at
../../gcc-4_3-branch/gcc/cp/pt.c:10887
#7 0x0046d656 in count_non_default_template_args (args=0x7fa41a459b40,
params=0x7fa41a443c00)
at ../../gcc-4_3-branch/gcc/cp/error.c:172
#8 0x0046fd64 in dump_template_parms (info=0x7fa41a45b750, primary=0,
flags=4) at ../../gcc-4_3-branch/gcc/cp/error.c:1343
#9 0x0046e387 in dump_aggr_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:548
#10 0x0046dba5 in dump_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:342
#11 0x0046f80a in dump_function_decl (t=0x7fa41a45c480, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:1162
#12 0x0046f0e7 in dump_decl (t=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:947
#13 0x0047199b in decl_as_string (decl=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:2220
#14 0x004719ca in lang_decl_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/error.c:2230
#15 0x004bfbc9 in cxx_printable_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/tree.c:1207
#16 0x00472143 in cp_print_error_function (context=0x10aeb40,
diagnostic=0x7fff28b42670) at ../../gcc-4_3-branch/gcc/cp/error.c:2471
#17 0x00471f32 in cp_diagnostic_starter (context=0x10aeb40,
diagnostic=0x7fff28b42670) at ../../gcc-4_3-branch/gcc/cp/error.c:2424
#18 0x005bc1b3 in diagnostic_report_diagnostic (context=0x10aeb40,
diagnostic=0x7fff28b42670)
at ../../gcc-4_3-branch/gcc/diagnostic.c:421
#19 0x005bcc7a in internal_error (gmsgid=0xc2a3e7 in %s, at %s:%d) at
../../gcc-4_3-branch/gcc/diagnostic.c:606
#20 0x005bcdfe in fancy_abort (file=0xbe1418
../../gcc-4_3-branch/gcc/cp/pt.c, line=15585, function=0xbe60f0
dependent_type_p)
at ../../gcc-4_3-branch/gcc/diagnostic.c:660
#21 0x00452025 in dependent_type_p (type=0x7fa41a45acc0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15585
#22 0x00495f83 in cxx_sizeof_or_alignof_type (type=0x7fa41a45acc0,
op=250, complain=1 '\001')
at ../../gcc-4_3-branch/gcc/cp/typeck.c:1289
#23 0x00447db8 in tsubst_copy_and_build (t=0x7fa41a443b80,
args=0x7fa41a459b40, complain=tf_none, in_decl=0x0, function_p=0 '\0',
integral_constant_expression_p=1 '\001') at
../../gcc-4_3-branch/gcc/cp/pt.c:10887
#24 0x0046d656 in count_non_default_template_args (args=0x7fa41a459b40,
params=0x7fa41a443c00)
at ../../gcc-4_3-branch/gcc/cp/error.c:172
#25 0x0046fd64 in dump_template_parms (info=0x7fa41a45b750, primary=0,
flags=4) at ../../gcc-4_3-branch/gcc/cp/error.c:1343
#26 0x0046e387 in dump_aggr_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:548
#27 0x0046dba5 in dump_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:342
#28 0x0046f80a in dump_function_decl (t=0x7fa41a45c480, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:1162
#29 0x0046f0e7 in dump_decl (t=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:947
#30 0x0047199b in decl_as_string (decl=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:2220
#31 0x004719ca in
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #41 from pluto at agmk dot net 2008-09-23 10:12 --- and the lastest patch causes internal error in cc1plus in my codebase: $ /local/devel/toolchain43/x86_64-gnu-linux.host64.diag/bin/x86_64-gnu-linux-g++ smsSimClock.ii -c -std=gnu++0x Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #42 from pluto at agmk dot net 2008-09-23 10:13 --- Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) internal-error-testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #43 from b0ntrict0r at yandex dot ru 2008-09-23 14:31 --- (In reply to comment #42) Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) [edit] internal-error-testcase Hm... I can reproduce it with gcc 4.3.2 and cannot reproduce with 4.3.1: original and patches gcc 4.3.1 works correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #39 from b0ntrict0r at yandex dot ru 2008-09-22 15:12 --- Created an attachment (id=16380) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380action=view) Updated fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #40 from pluto at agmk dot net 2008-09-22 21:54 ---
(In reply to comment #39)
Created an attachment (id=16380)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380action=view) [edit]
Updated fixed
1). still there is a warning:
../../gcc/cp/error.c: In function 'dump_template_argument_list':
../../gcc/cp/error.c:190: warning: signed and unsigned type in conditional
expression
2). seems to work, but...
#include set
#include string
template typename T, typename S = std::set std::string , int N = 1
struct X
{
virtual ~X() = 0;
};
void f()
{
X float x; // error here.
}
$ g++ d2.cpp -c
d2.cpp: In function #8216;void f()#8217;:
d2.cpp:10: error: cannot declare variable #8216;x#8217; to be of abstract
type #8216;Xfloat#8217;
d2.cpp:5: note: because the following virtual functions are pure within
#8216;Xfloat#8217;:
d2.cpp:6: note: XT, S, N::~X() [with T = float, S =
std::setstd::basic_stringchar , int N = 1]
d2.cpp:6: note could look like 'XT, S, N::~X() [with T = float]'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #38 from pluto at agmk dot net 2008-09-22 09:21 ---
(In reply to comment #37)
Created an attachment (id=16361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361action=view) [edit]
Updated patch
Could someone test updated patch?
it doesn't build.
../../gcc/cp/error.c: In function 'dump_template_argument':
../../gcc/cp/error.c:144: warning: passing argument 2 of
'dump_template_argument_list' makes pointer from integer without a cast
../../gcc/cp/error.c:144: error: too few arguments to function
'dump_template_argument_list'
../../gcc/cp/error.c: In function 'count_non_default_template_args':
../../gcc/cp/error.c:159: error: expected declaration specifiers before ')'
token
../../gcc/cp/error.c:184: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:212: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:258: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:302: error: expected declaration specifiers before '}'
token
../../gcc/cp/error.c:309: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:463: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:478: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:494: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:562: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:671: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
(...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #37 from b0ntrict0r at yandex dot ru 2008-09-19 12:22 --- Created an attachment (id=16361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361action=view) Updated patch Could someone test updated patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #36 from pluto at agmk dot net 2007-10-15 14:04 --- could someone update this patch for 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #35 from pcarlini at suse dot de 2007-10-12 11:04 --- *** Bug 33747 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 foo1U::pointer,
typename foo2V::pointer
b(0);
};
};
bazint,int x;
You'll get a message that says:
line 20: error: a value of type foo2int::pointer cannot be
used to initialize an entity of type foo1int::pointer
U u = v;
^
detected during:
instantiation of barU, V::bar(V) [with U=foo1int::pointer,
V=foo2int::pointer] at line 32
instantiation of bazU, V::baz() [with U=int, V=int] at line 36
It is the appearance of foo1int::pointer and foo2int::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
foo2T::pointer could easily have been some other template:
template class T
struct foo1
{
typedef typename foobarT::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
--- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 vectorint, I would like to print vectorT [with T = int], not vectorint, default (or variants). Similarly, if user wirtes vectorint, allocatorint , then ideally I would also like to print vectorT, Allocator [with T = int, Allocator = alloctorint]. 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
--- 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
--- 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::mapstd::string, std::vectorint m;
void bar(void)
{
std::vectorint 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::vectorint, _T1 = const
std::string, _T2 = std::vectorint]':
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::vectorint,
std::allocatorint , _T1 = const std::string, _T2 = std::vectorint,
std::allocatorint ]':
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_traitschar, _Alloc =
std::allocatorchar]'
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
--- 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::vectorT v;
void foo(void)
{ v.doesnotexist(); }
};
void foo(void)
{
Aint,0 a;
a.foo();
}
---
Patched:
test.cc: In member function 'void AT, N, X::foo() [with T = int]':
test.cc:14: instantiated from here
test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist'
Unpatched:
test.cc: In member function `void AT, N, X::foo() [with T = int, int N = 0,
int X = 1]':
test.cc:14: instantiated from here
test.cc:9: error: 'class std::vectorint, std::allocatorint ' 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
--- 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 [EMAIL PROTECTED] 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::mapstd::string, std::vectorint m;
|
| void bar(void)
| {
| std::vectorint 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::vectorint, _T1 = const
| std::string, _T2 = std::vectorint]':
| 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
--- 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 AT, N, X::foo() [with T = int]': test.cc:14: instantiated from here test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist' That's a good improvement, but do you think you could write the first line with AT instead of AT,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
--- 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 AT, N, X::foo() [with T = int]': test.cc:14: instantiated from here test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist' That's a good improvement, but do you think you could write the first line with AT instead of AT,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 AT instead of AT,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
--- 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
--- 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 [EMAIL PROTECTED] writes: | (In reply to comment #31) | | Patched: | test.cc: In member function 'void AT, N, X::foo() [with T = int]': | test.cc:14: instantiated from here | test.cc:9: error: 'class std::vectorint' has no member | named 'doesnotexist' | | That's a good improvement, but do you think you could write the first line | with AT instead of AT,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 AT instead of AT,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
[Bug c++/14912] Do not print default template arguments in error messages
--- 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 [EMAIL PROTECTED] 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)
| {
| Avoid,0 a;
| }
| ---
| test.cc: At global scope:
| test.cc: In instantiation of 'Avoid, 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 'Avoid, 0' or 'Avoid'? 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
--- 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 [EMAIL PROTECTED] writes: | The first non-trivial issue is that, in order to print std::vectorint | instead of std::vectorint, std::allocatorint , 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 AT, 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
--- 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 [EMAIL PROTECTED] writes: | --- Additional Comments From giovannibajo at libero dot it 2005-03-23 11:01 --- | or maybe: | | test.cc: In member function `void AT, 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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::allocatorT (with T being a previous template parameter), while the type in the instantiation is something like std::allocatorint. 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
--- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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)
| {
| Avoid,0 a;
| }
| ---
| test.cc: At global scope:
| test.cc: In instantiation of 'Avoid, 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 'Avoid, 0' or 'Avoid'? In other
words,
Most of the time, we want to print what user wrote.
That rule could be really bad in cases like:
Avoid, foobar::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
foobar::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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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::allocatorT (with T being a previous | template parameter), while the type in the instantiation is something like | std::allocatorint. | | 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
--- 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 [EMAIL PROTECTED] 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
--- 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::vectorint instead of std::vectorint, std::allocatorint , 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 AT, 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 AT, 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
--- Additional Comments From giovannibajo at libero dot it 2005-03-23 11:01 --- or maybe: test.cc: In member function `void AT, 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
--- 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 vectorT or include A in the with clause of vectorT,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. vectorint 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
--- 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
--- 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)
{
Avoid,0 a;
}
---
test.cc: At global scope:
test.cc: In instantiation of 'Avoid, 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 'Avoid, 0' or 'Avoid'? 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
--- 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
