On 11/19/23 08:39, waffl3x wrote:
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 don't think so: https://eel.is/c++draft/expr.prim#lambda.closure-5
says the type of the xobj parameter must be related.
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());
}
This should be rejected when we try to instantiate the op() with int.
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) {};
}
Here I think the problem is in build_capture_proxy:
/* The proxy variable forwards to the capture field. */
object = build_fold_indirect_ref (DECL_ARGUMENTS (fn));
object = finish_non_static_data_member (member, object, NULL_TREE);
The call to build_fold_indirect_ref assumes that 'this' is a pointer,
which it is not here. I think you can just make that conditional on it
being a pointer or reference?
Jason
