In a pre-standard version of the constexpr specification use of 'this'
was not valid in a constexpr function except as part of a member access.
We dropped the notion of potential constant expression from the
standard, in favor of just saying that a constexpr function that can
never produce a constant expression is ill-formed, no diagnostic
required. We still use potential_constant_expression_1 to give a
diagnostic where reasonable, but clearly it is not reasonable in this
case and we should drop this check from that function. Any actually
problematic use of 'this' will show up when we try to actually get a
constant value.
Tested x86_64-pc-linux-gnu, applying to trunk. I'm not bothering to add
a testcase because Benjamin needs this for tuple, so it will be tested
there.
commit 3d177986ce1b5fcf030a0928e155673459547410
Author: Jason Merrill <ja...@redhat.com>
Date: Tue Aug 16 23:22:57 2011 -0400
* semantics.c (potential_constant_expression_1): Allow 'this'.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 59b25e5..1f6b49a 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7681,21 +7681,7 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
case IDENTIFIER_NODE:
/* We can see a FIELD_DECL in a pointer-to-member expression. */
case FIELD_DECL:
- return true;
-
case PARM_DECL:
- /* -- this (5.1) unless it appears as the postfix-expression in a
- class member access expression, including the result of the
- implicit transformation in the body of the non-static
- member function (9.3.1); */
- /* FIXME this restriction seems pointless since the standard dropped
- "potential constant expression". */
- if (is_this_parameter (t))
- {
- if (flags & tf_error)
- error ("%qE is not a potential constant expression", t);
- return false;
- }
return true;
case AGGR_INIT_EXPR:
