On 4/4/25 9:25 AM, Patrick Palka wrote:
On Fri, 4 Apr 2025, Patrick Palka wrote:
On Thu, 3 Apr 2025, Jason Merrill wrote:
On 4/2/25 2:28 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
OK for 14.
For 15, what happens if we remove that error entirely? Do we still give other
errors in that case? That seems to be the expectation of
https://eel.is/c++draft/basic.scope.param#note-1 and I'd expect that in a
constant-evaluated (and therefore evaluated) context we would complain about
it not being constant.
Indeed, it seems we do reliably error elsewhere if we remove that error,
e.g. for parse/parameter-declaration-2.C we instead emit give:
error: size of array ‘p’ is not an integral constant-expression
But regtesting revealed that error path is also used to disambiguate
vexing parses -- removing it causes us to now reject parse/ambig7.C:
parse/ambig7.C:16:36: error: no matching function for call to ‘Helper::Helper(int,
<unresolved overloaded function type>)’
So I guess we can't remove it outright just yet.
This seems to be because cp_parser_template_id wrongly does the
CPP_TEMPLATE_ID transformation with the A PARM_DECL, so the re-parse as
an expression can't switch to referring to the right A. And removing
the cp_error_occurred check breaks libstdc++.
So yeah, not seem simple enough for GCC 15, your patch is OK.
Forgot to mention, removing the error is also unfortunately not
sufficient to fix the related PR104255. For e.g.
template<int> struct A;
struct empty { };
constexpr int f(empty) { return 0; }
auto g(empty e) -> A<f(e)>*;
template<class T> auto h(T t) -> A<f(t)>*;
int main() {
g(empty{}); // now OK
h(empty{}); // now ICE instead of error
}
the call to the (non-template) g is now accepted, but for the call to
(template) h we now hit the cp_unevaluated_operand assert from the
PARM_DECL case of tsubst_expr.
It might be useful to have a test that we are in an
only-constant-evaluated context rather than a normal evaluated context?
Though I guess you can have odr-use in a constant-evaluated context as
well, if we take the address of the variable, so maybe it wouldn't have
much use.
Jason
