Hi, The attached code emits a mysterious error: $ g++ -c foo.cc foo.cc: In function 'int main()': foo.cc:13: error: '<anonymous enum>' is/uses anonymous type foo.cc:13: error: trying to instantiate 'template<class T> void operator<<(MyClass&, const T&)' $ The compiler apparently fails to see that the anonymous enum can be cast to an integer.
There is some discussion on the list about this. Right now there is a DR report about this and about is this really invalid code or not.
Suspending as there is still questions is this really invalid code or not.
Created attachment 8860 [details] test case
Whether the code is valid or not, please improve the error message :-)
I don't see any how to improve the error message really since it says what the problem is.
I think the first line could be made clearer: '<anonymous enum>' is/uses anonymous type I'm reading it again and again, and it doesn't make sense to me. Then the second line refers to an operator<< most probably defined in some remote header file. This is distracting. I would suggest not printing this second line at all.
I'm not sure what a DR is, probably a C++ standard defect report. After asking on fr.comp.lang.c++ I was referred to Core Issue 278: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#278 Whether the compiler should compile the code or not, the error message really needs to be improved. My understanding of the situation is that : 1.a) The compiler first attempts to apply the shift operator to integer "i". However the right-side argument is an anonymous enum. The compiler will not implictly cast the anonymous enum to a size_t to be used as the right-hand argument for operator<<. 1.b) Note that an *explicit* cast does work, so I'm not sure how this whole issue is related to Core Issue 278 and external linkage. Just change from: i<<HSize; to: i<<int(HSize); and the program while compile and link. 2) The compiler then attemps to use operator<<(MyClass& b, const T& t). Instead of reporting an error on the first argument (type 'MyClass' expected, type 'int' actually used), it reports an obscure error on the second argument. This is totally non-intuitive for humans. Therefore: * Concerning 1.a) and 1.b) I'm not convinced this is related to Core Issue 278 and external linkage since the explicit cast works. Anyway, if you feel Core Issue 278 or some paragraph of the standard forbid the implicit cast, I agree this bug report should be kept open until the comitee resolves the problem. * In the meanwhile, the error message really needs to be improved, taking into account point 2).
Subject: Re: templates and anonymous enum "papadopo at shfj dot cea dot fr" <gcc-bugzilla@gcc.gnu.org> writes: [...] | Therefore: | | * Concerning 1.a) and 1.b) I'm not convinced this is related to Core Issue 278 | and external linkage since the explicit cast works. Anyway, if you feel Core | Issue 278 or some paragraph of the standard forbid the implicit cast, I agree | this bug report should be kept open until the comitee resolves the problem. The way it is related is that the CWG has introduced the concent of linkage for type -- which did not exist in ARM and existed only for function type in C++98/03 and the unnamed enum no longer has an external linkage. As I said on fr.comp.lang.c++, I brought the issue to the C++ committee and I think the issue should not be closed. The answer I gave you was much more detailed and accurate that what you report here :-) -- in particular, the ocmpiler is attempting to do overload resolution and it is in the phase of constructing the overload set that the error appears. But, the whole thing is confused :-) -- Gaby
I guess what I meant is: whatever the reason for this error message and whatever the eventual decision taken about it, it would be nice to have an error message that really means something to end-users. For example, as an end-user, I still can't understand the difference between the explicit cast and the implicit (non-)cast, why it works in the first case and not in the latter. The error message shoudl really point at what's wrong in the source code, not at what's wrong in the C++ standard.
> .......... The error message shoudl really point at what's wrong in the > source code, not at what's wrong in the C++ standard. But unfortunately if the compiler is conforming, and the latter is wrong, the former is "correct" as-is and the error message too ;)
Subject: Re: [DR 278] templates and anonymous enum "papadopo at shfj dot cea dot fr" <gcc-bugzilla@gcc.gnu.org> writes: | I guess what I meant is: whatever the reason for this error message | and whatever the eventual decision taken about it, it would be nice | to have an error message that really means something to end-users. 100% agreed. -- Gaby
OK, then what I really meant is that error message doesn't mean anything in plain English, thus it doesn't mean anything to end-users. So it needs to be improved. I understand it's not easy - after all no one here is able to explain what really is behind this bug. I'm not a native speaker, I'm just a rather skilled end-user; I can nevertheless guarantee that end-users don't understand this error message. We spent a few hours trying and finding what needs to be changed in some 3rd party library we're using, because the compiler was pointing to a totally unrelated template definition of operator<< in our own sources.
Subject: Re: [DR 278] templates and anonymous enum "pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes: | > .......... The error message shoudl really point at what's wrong in the | > source code, not at what's wrong in the C++ standard. | | But unfortunately if the compiler is conforming, and the latter is wrong, | the former is "correct" as-is and the error message too ;) I think his point is that the diagnostic message is not helpful. And I agree with him. -- Gaby
*** Bug 21701 has been marked as a duplicate of this bug. ***
Not specific to sparc-sun-solaris2.8.
*** Bug 22505 has been marked as a duplicate of this bug. ***
Why is this marked as DR 278? I think it's DR 488.
Subject: Bug 21514 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2005-09-16 15:41:45 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/template: crash19.C local4.C Log message: PR c++/21514 * pt.c (check_instantiated_args): Treat uses of anonymous types as causing type-deduction failure. PR c++/21514 * g++.dg/template/crash19.C: Remove dg-error marker. * g++.dg/template/local4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4895&r2=1.4896 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1037&r2=1.1038 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6070&r2=1.6071 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash19.C.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/local4.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
Subject: Bug 21514 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: mmitchel@gcc.gnu.org 2005-09-16 15:43:14 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/template: crash19.C local4.C Log message: PR c++/21514 * pt.c (check_instantiated_args): Treat uses of anonymous types as causing type-deduction failure. PR c++/21514 * g++.dg/template/crash19.C: Remove dg-error marker. * g++.dg/template/local4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.105&r2=1.4648.2.106 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.26&r2=1.978.2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.407&r2=1.5084.2.408 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash19.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3&r2=1.3.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/local4.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2.6.1&r2=1.2.6.2
Fixed in 4.0.2.
*** Bug 20589 has been marked as a duplicate of this bug. ***
/me wishes this was backported to *-apple-darwin8 gcc (Xcode 2.5)