[Clang] Deducing this Lambda does not generate all the needed function calls

[Link1J]

Found when reporting #86398, so it may be related to it. But with the following valid code, at all optimization levels, the following code does not generate correctly.

volatile int a = 0;
struct function {
    function& operator=(function const&) {
        a = 1;
        return *this;
    }
};
int main() {
    function list;
    [&list](this auto self) {
        list = function{};
    }();
}

Clang does not generate a call to function::operator=, and therefor does not set a to 1. Both GCC and MSVC generate the code correctly. Godbolt

[Sirraide]

Also fixed by #84473. I’ll add a test for this as well.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Jared Irwin (Link1J)

Found when reporting #86398, so it may be related to it. But with the following valid code, at all optimization levels, the following code does not generate correctly. ```c++ volatile int a = 0; struct function { function& operator=(function const&) { a = 1; return *this; } }; int main() { function list; [&list](this auto self) { list = function{}; }(); } ``` Clang does not generate a call to `function::operator=`, and therefor does not set `a` to 1. Both GCC and MSVC generate the code correctly. [Godbolt](https://godbolt.org/z/9q5zYP9Ea)

[shafik]

@Sirraide if you confirm a bug please add the confirmed tag to it

[Sirraide]

@Sirraide if you confirm a bug please add the confirmed tag to it

There was a dicussion about this on Discourse not too long ago that left it kind of open as to what our policy on this was, but I can add it in the future, sure.

It might help to clarify that somewhere (unless we’re already doing that and I just missed it) and maybe also that it’s handled differently across different subprojects so other people don’t get confused about this too, because I recall some of the people working on other parts of LLVM said they thought the label was kind of pointless.

[shafik]

@Sirraide if you confirm a bug please add the confirmed tag to it

There was a dicussion about this on Discourse not too long ago that left it kind of open as to what our policy on this was, but I can add it in the future, sure.

It might help to clarify that somewhere (unless we’re already doing that and I just missed it) and maybe also that it’s handled differently across different subprojects so other people don’t get confused about this too, because I recall some of the people working on other parts of LLVM said they thought the label was kind of pointless.

It is definitely not pointless for front-end bugs. A lot of bugs on the front end are not obvious. Crashes are easy, they are always a bug, but maybe fixed on trunk let's say. Other bugs may look like bugs but clang may actually be correct and someone needs to verify that they believe clang is not conforming.

[Sirraide]

It is definitely not pointless for front-end bugs. A lot of bugs on the front end are not obvious. Crashes are easy, they are always a bug, but maybe fixed on trunk let's say. Other bugs may look like bugs but clang may actually be correct and someone needs to verify that they believe clang is not conforming.

Yeah, makes sense; in this case I specifically didn’t add the label because I’d already linked a pr that fixes this so I thought it was maybe a bit redundant, but I can do that in the future.