On Sunday, November 19th, 2023 at 9:31 AM, Jason Merrill <ja...@redhat.com> wrote:
> > > 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. Well, thanks for bringing that to my attention, that makes things easier but I'm kinda disappointed, I almost wanted an excuse to write more code. I wonder why Gasper thought this wasn't the case, perhaps it was a later decision? Okay, I checked, that paragraph is in the original paper, I thought I could just take what one of the paper's authors said for granted but I guess not, I'm not going to make that mistake again. On the other hand, maybe he just misunderstood my question, what can you do. Well regardless, that reduces the things I have left to do by a whole lot. > > 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. Yep, absolutely, that is clear now. Just for the record, clang accepts it, but since I can't think of any use cases for this I don't think there's any value in supporting it. > > > 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 Thanks, I will take a look at that area. I'm having trouble fixing the error for this case, the control flow when the functions are overloaded is much more complex. struct S { void f(this S&) {} void f(this S&, int) void g() { void (*fp)(S&) = &f; } }; This seemed to have fixed the non overloaded case, but I'm also not very happy with it, it feels kind of icky. Especially since the expr's location isn't available here, although, it just occurred to me that the expr's location is probably stored in the node. typeck.cc:cp_build_addr_expr_1 ``` case BASELINK: arg = BASELINK_FUNCTIONS (arg); if (DECL_XOBJ_MEMBER_FUNC_P ( { error ("You must qualify taking address of xobj member functions"); return error_mark_node; } Anyway, I'm quite tired but I'll to finish off the lambda stuff before calling it, then I'll run a bootstrap and tests and if all is well I will submit the patch. I will probably skimp on the changelog and commit message as that's the part I have the hardest time on, especially when I'm tired. Alex ```
