The following code causes a mysterious error. __FUNCTION__ and __PRETTY_FUNCTION__ cause the same problem as __func__, too. cryolite@thinblue:~/work/gcc_bug/func_in_lambda$ g++-4.5.0 -v -save-temps -std=c++0x main.cpp Using built-in specs. COLLECT_GCC=g++-4.5.0 COLLECT_LTO_WRAPPER=/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/lto-wrapper Target: i486-linux-gnu Configured with: ../gcc-4.5.0/configure --build=i486-linux-gnu --prefix=/home/cryolite/local --program-suffix=-4.5.0 --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc' '-mtune=i486' '-march=i486' /home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -E -quiet -v -D_GNU_SOURCE main.cpp -mtune=i486 -march=i486 -std=c++0x -fpch-preprocess -o main.ii ignoring duplicate directory "/home/cryolite/local/include" ignoring nonexistent directory "/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/../../../../i486-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/cryolite/local/include /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++ /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/i486-linux-gnu /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/backward /usr/local/include /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc' '-mtune=i486' '-march=i486' /home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=i486 -march=i486 -auxbase main -std=c++0x -version -o main.s GNU C++ (GCC) version 4.5.0 (i486-linux-gnu) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967 GNU C++ (GCC) version 4.5.0 (i486-linux-gnu) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967 Compiler executable checksum: f3cfa96cf9dcd630b91f4110d3b8b2b3 cc1plus: error: declaration of 'const char __func__ [5]' main.cpp:3:17: error: conflicts with previous declaration 'const char __func__ [11]' cryolite@thinblue:~/work/gcc_bug/func_in_lambda$ cat main.ii # 1 "main.cpp" # 1 "<built-in>" # 1 "<command-line>" # 1 "main.cpp" int main() { []() { return __func__; }; __func__; }
4.5.3, 4.6 and mainline say: 44160.C: In lambda function: 44160.C:3:27: error: return-statement with a value, in function returning 'void' [-fpermissive] Is it good enough?
No, the return type should be deduced as const char *.
Oops, indeed. Thanks.
Things go wrong well before check_return_expr: in cp_parser_lambda_body, cp_parser_expression returns error_mark_node.
More debugging: fname_decl, called by finish_fname, returns error_mark_node, whereas it doesn't for, eg, 'const char* f() { return __func__; }'. Note the argument to finish_fname is completely similar in the two cases.
I found where exactly things go wrong first: in cp_make_fname_decl, current_binding_level->kind is sk_function_parms, thus error_mark_node is returned. In the aforementioned case of f(), it's sk_block, makes sense. Jason, any tip about this meaningless binding level?
A do_pushlevel(sk_block) missing?
Author: jason Date: Thu Jun 16 22:09:28 2011 New Revision: 175123 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175123 Log: PR c++/44160 * parser.c (cp_parser_lambda_body): Share code between simple and complex cases instead of using cp_parser_function_body. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
Fixed for 4.7.