This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Lazy __FUNCTION__ etc
- To: "Zack Weinberg" <zackw at stanford dot edu>
- Subject: Re: RFC: Lazy __FUNCTION__ etc
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 21 Mar 2001 06:17:49 +0100
- Cc: gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20010320200540.B3208@stanford.edu>
"Zack Weinberg" <email@example.com> writes:
| The patch is not quite ready for inclusion, because it somehow breaks
| C++'s ext/pretty3.C and ext/pretty4.C tests.
I've always been uncomfortable with the way, these tests were designed
-- I think they're taking the wrong way.
| ... I believe pretty4 is in
| error: it wants __FUNCTION__ to be a different object from a string
| constant with the same contents, and a different object for two
| (overloaded) functions with the same base name. This has never been
| true in the C compiler, but apparently used to be true for C++. I
| would just change the test to match, but it's all templates and I
| don't know how to hack it up properly.
There is no clear documentation about how __FUNCTION__ should act in
C++. I think we should me make it match C's semantics. However, for
template specializations, we want to print
| pretty3, on the other hand, is a genuine problem. We've got a generic
| template function, and an explicit specialization. Then main calls
| the explicit specialization, and the generic version (causing an
| implicit specialization). Formerly, __PRETTY_FUNCTION__ was not
| evaluated for template functions until they were specialized, so both
| of them came out like "f1(T) [with T = float]". Now
| __PRETTY_FUNCTION__ is evaluated immediately, so the generic is just
| called "f1(T)". This is undesired. I do not know why it happened or
| how to put the semantics back the way they were - I do see some code
| aimed at evaluating _P_F_ at template specialization time, in pt.c,
| but I have no idea how we get there...
The proper way to do it is to introduce new functions to do the right
thing. Currently we're using bits from cp/errors.c but that is
fragile and wrong. It's fragile because any change to how we display
function declarations in diagnostics affects __PRETTY_FUNCTION__. It
is wrong because it is using the wrong semantics.
Hope that helps,
CodeSourcery, LLC http://www.codesourcery.com