diff options
| author | Jason Merrill <jason@redhat.com> | 2025-04-04 17:34:08 -0400 |
|---|---|---|
| committer | Jason Merrill <jason@redhat.com> | 2025-04-04 23:37:53 -0400 |
| commit | 7d561820525fd3b9d8f3876333c0584d75e7c053 (patch) | |
| tree | 02d0d09e475211b0a993a65f1d00b964a3095fbb /libjava/classpath/javax/management/MBeanRegistrationException.java | |
| parent | 2f62e66e1444d858e937faa7147f6cd06296b33b (diff) | |
| download | gcc-7d561820525fd3b9d8f3876333c0584d75e7c053.zip gcc-7d561820525fd3b9d8f3876333c0584d75e7c053.tar.gz gcc-7d561820525fd3b9d8f3876333c0584d75e7c053.tar.bz2 | |
c++: __FUNCTION__ in lambda return type [PR118629]
In this testcase, the use of __FUNCTION__ is within a function parameter
scope, the lambda's. And P1787 changed __func__ to live in the parameter
scope. But [basic.scope.pdecl] says that the point of declaration of
__func__ is immediately before {, so in the trailing return type it isn't in
scope yet, so this __FUNCTION__ should refer to foo().
Looking first for a block scope, then a function parameter scope, gives us
the right result.
PR c++/118629
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl_outermost_localscope): Look for an
sk_block.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-__func__3.C: New test.
Diffstat (limited to 'libjava/classpath/javax/management/MBeanRegistrationException.java')
0 files changed, 0 insertions, 0 deletions