Re: RFC: Lazy __FUNCTION__ etc

[Gabriel Dos Reis <gdr at codesourcery dot com>]

"Zack Weinberg" <zackw@stanford.edu> 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

	function-template-name<template-argument-list>

| 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.

	f1<float>(float)

Hope that helps,

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com