Re: ICE: malformed code gives ICE for &(C::m)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mike Stump <mrs@apple.com> writes:

| On Monday, August 5, 2002, at 04:04 PM, Gabriel Dos Reis wrote:
| 
| > Mike Stump <mrs@apple.com> writes:
| >
| > | Ping...
| > |
| > | http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01427.html
| >
| > Hi,
| >
| > I crossed the ICE you're fixing and I'm wondering if it wouldn't be
| > better to fix it at the point of construction of &(C::m) since that
| > already is invalid if m is member function.
| 
| [ blink ] Do you realize that this is code called out of the parser for 
| & at build time?

For sure.  Is there anything that indicates the contrary?

Upon seeing &(C::m), the parser calls finish_unary_op_expr() which in
turns calls build_x_unary_op().  My point is that since &(C::m) is
invalid construct when m is a member function, build_x_unary_op()
shouldn't have left out something that will end up being nonsensical.
Therefore my thought is this: build_x_unary_op() should

  (1) issue a diagnostic for &(C::m) if m is member-function and
       (a) either return error_mark_node, or
       (b) try to build a sensical representation (DTRT)

  (2) build a pointer-to-non-member is m is data member.

That I think is much robust than trying to recover the situtation only
very late at initialization time.  I don't think that means I didn't
realize that is code called out of the parser for & at build time.

-- Gaby