Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x <waffl3x@protonmail.com>]

Funny enough I ended up removing the ones I was thinking about, seems
to always happen when I ask style questions but I'm glad to hear it's
okay going forward.

I'm having trouble fixing this bug, based on what Gasper said in
PR102609 I am pretty sure I know what the semantics should be. Since
the capture is not used in the body of the function, it should be well
formed to call the function with an unrelated type.

I had begun trying to tackle the case that Gasper mentioned and got the
following ICE. I also have another case that ICEs so I've been thinking
I don't get to do little changes to fix this. I've been looking at this
for a few hours now and given we are past the deadline now I figured I
should see what others think.

int main()
{
  int x = 42;
  auto f1 = [x](this auto&& self) {};

  static_cast<int(*)(int&)>(decltype(f1)::operator());
}

explicit-obj-lambdaX3.C: In instantiation of 'main()::<lambda(auto:1&&)> static [with auto:1 = int&]':
explicit-obj-lambdaX3.C:33:53:   required from here
   33 |   static_cast<int(*)(int&)>(decltype(f1)::operator());
      |                                                     ^
explicit-obj-lambdaX3.C:31:33: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in finish_non_static_data_member, at cp/semantics.cc:2294
   31 |   auto f1 = [x](this auto&& self) {};
      |                                 ^
0x1c66dda tree_check_failed(tree_node const*, char const*, int, char const*, ...)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.cc:8949
0xb2e125 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.h:3638
0xedfaf4 finish_non_static_data_member(tree_node*, tree_node*, tree_node*, int)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/semantics.cc:2294
0xe8b9b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:20864
0xe6d713 tsubst_decl
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:15387
0xe6fb1b tsubst(tree_node*, tree_node*, int, tree_node*)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:15967
0xe7bd81 tsubst_stmt
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:18299
0xe7df18 tsubst_stmt
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:18554
0xea6982 instantiate_body
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:26743
0xea83e9 instantiate_decl(tree_node*, bool, bool)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:27030
0xb5f9c9 resolve_address_of_overloaded_function
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/class.cc:8802
0xb60be1 instantiate_type(tree_node*, tree_node*, int)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/class.cc:9061
0xaf9992 standard_conversion
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:1244
0xafcb57 implicit_conversion
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:2081
0xb2a8cb perform_direct_initialization_if_possible(tree_node*, tree_node*, bool, int)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:13456
0xf69db8 build_static_cast_1
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:8356
0xf6af1b build_static_cast(unsigned int, tree_node*, tree_node*, int)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:8566
0xd9fc02 cp_parser_postfix_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:7531
0xda45af cp_parser_unary_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:9244
0xda5db4 cp_parser_cast_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:10148

As I said, there is also this case that also ICEs in the same region.
It's making me think that some core assumptions are being violated in
the code leading up to finish_non_static_data_member.

int main()
{
  int x = 42;
  auto f1 = [x](this auto self) {};
}

explicit-obj-lambdaX3.C: In lambda function:
explicit-obj-lambdaX3.C:31:31: internal compiler error: Segmentation fault
   31 |   auto f1 = [x](this auto self) {};
      |                               ^
0x1869eaa crash_signal
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/toplev.cc:315
0xb2ea0b strip_array_types(tree_node*)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.h:4955
0xf773e2 cp_type_quals(tree_node const*)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:11509
0xedf993 finish_non_static_data_member(tree_node*, tree_node*, tree_node*, int)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/semantics.cc:2271
0xcc3e12 build_capture_proxy
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/lambda.cc:410
0xcce99a start_lambda_function(tree_node*, tree_node*)
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/lambda.cc:1684
0xdab196 cp_parser_lambda_body
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:12004
0xda8f64 cp_parser_lambda_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:11293
0xd9c03a cp_parser_primary_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:5921
0xda0b33 cp_parser_postfix_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:7868
0xda45af cp_parser_unary_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:9244
0xda5db4 cp_parser_cast_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:10148
0xda5ecd cp_parser_binary_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:10251
0xda6fd9 cp_parser_assignment_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:10595
0xda77b3 cp_parser_constant_expression
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:10885
0xdc9a36 cp_parser_initializer_clause
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:25844
0xdc981d cp_parser_initializer
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:25783
0xdc40bd cp_parser_init_declarator
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:23332
0xdb46d2 cp_parser_simple_declaration
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:15690
0xdb41e5 cp_parser_block_declaration
	/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:15510

Any insight is appreciated here, I've been going through with GDB and I
do feel like I'm making progress, but I'm not much closer to figuring
out what the correct solution (to the first) is.

Right now, my plan is when trying to access captures, it should be
checking to see if the type of the xobj param passed in is related to
the context of the function decl. I just haven't figured out exactly
where to insert it yet. With any luck, now that I've written an e-mail
saying I'm having trouble I'll immediately figure out what to do. It's
happened every previous time so far. :)

Alex

On Saturday, November 18th, 2023 at 11:22 PM, Jason Merrill <jason@redhat.com> wrote:


> 
> 
> On Sat, Nov 18, 2023 at 1:43 AM waffl3x waffl3x@protonmail.com wrote:
> 
> > The patch is coming along, I just have a quick question regarding
> > style. I make use of IILE's (immediately invoked lambda expression) a
> > whole lot in my own code. I know that their use is controversial in
> > general so I would prefer to ask instead of just submitting the patch
> > using them a bunch suddenly. I wouldn't have bothered either but this
> > part is really miserable without them.
> 
> 
> We don't use them much currently, but I'm not opposed to them either,
> if they help make the code clearer.
> 
> > If that would be okay, I would suggest an additional exception to
> > bracing style for lambdas.
> > This:
> > {
> > // stuff
> > };
> > Instead of this:
> > 
> > {
> > // stuff
> > };
> 
> 
> Makes sense.
> 
> Jason