[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b323f52ccf966800297b0520b9e1d4b3951db525 commit r13-6722-gb323f52ccf966800297b0520b9e1d4b3951db525 Author: Jason Merrill Date: Thu Mar 16 15:11:25 2023 -0400 c++: generic lambda, local class, __func__ [PR108242] Here we are trying to do name lookup in a deferred instantiation of t() and failing to find __func__. tsubst_expr already tries to instantiate members of local classes, but was failing with the partial instantiation of generic lambdas. PR c++/108242 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) [TAG_DEFN]: Handle partial instantiation. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-func2.C: New test.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #7 from Jakub Jelinek ---
Sorry, above doesn't compile, but
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __PRETTY_FUNCTION__;
struct
{
constexpr const char* operator()() const { constexpr char const*
fun_name2 = __PRETTY_FUNCTION__; return fun_name; };
} t;
t();
};
fun(12);
}
int main() {
my_fun();
}
ICEs and compiles fine with G++ 11.x.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105809 CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- I was just looking into bug 105809 which looks like the same problem except with __PRETTY_FUNCTION__.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #5 from Jakub Jelinek ---
Makes me wonder why finish_fname returns the IDENTIFIER_NODE rather than the
VAR_DECL when processing_template_decl, though if I comment that out it ICEs.
When DECL_INITIAL is __FUNCTION__ etc. IDENTIFIER_NODE, it is looked up using
lookup_name, which works fine if it is the template function in which
__FUNCTION__ has been referenced (ok e.g. when processing DECL_EXPR of
fun_name). But for some reason
we don't find that VAR_DECL as local specialization and trigger
/* This can happen for a variable used in a
late-specified return type of a local lambda, or for a
local static or constant. Building a new VAR_DECL
should be OK in all those cases. */
r = tsubst_decl (t, args, complain);
if (local_specializations)
/* Avoid infinite recursion (79640). */
register_local_specialization (r, t);
if (decl_maybe_constant_var_p (r))
{
/* We can't call cp_finish_decl, so handle the
initializer by hand. */
tree init = tsubst_init (DECL_INITIAL (t), r, args,
complain, in_decl);
which then doesn't work, either it finds a different __FUNCTION__ than it
should, e.g. for:
bool v;
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __FUNCTION__;
struct
{
constexpr const char* operator()() const { return v ? __FUNCTION__
: fun_name; };
} t;
t();
};
fun(12);
}
or it doesn't find it at all.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The original testcase started to be rejected with r12-4425-g1595fe44e11a969d8ae462212886fb0a87b46226 The second one indeed starting with r8-2720-gf44a8dd56f5bfbd0596c39693e268ef880c06221
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84925, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82029 --- Comment #3 from Andrew Pinski --- related to PR 84925 and PR 82029 . The first one was caused by the second one and the second one was caused by r8-2720-gf44a8dd56f5bfb which I suspect might have introduced this bug ...
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |10.5 Known to work||7.1.0 Last reconfirmed||2022-12-28 Summary|'__FUNCTION__' was not |[10/11/12/13 Regression] |declared when used inside a |'__FUNCTION__' was not |generic (templated) lambda |declared when used inside a |declared inside a template |generic (templated) lambda |function|declared inside a template ||function Known to fail||8.1.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Note the original testcase works in GCC 8 to GCC 11 while my testcase in comment #1 fails with those versions. Would be interesting to see what patch broke the original testcase and my testcase.
