[clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

[Arthur O'Dwyer via cfe-commits]

On Fri, Mar 27, 2020 at 8:16 PM Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
wrote:

> Richard: Okay, filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94376 !
>
> David: You are correct, the bug in function_ref appeared only when
> constructing from `const function_ref&&`. When I said that the constructor
> template suppressed the copy constructor, I was wrong. The implicitly
> generated copy constructor is still there, and it's the best match for
> `const function_ref&` but not for `const function_ref&&`.  The bug would
> also appear with construction from `volatile function_ref&`, but, let's not
> go there. :)
>
> IMHO (YMMV), it would be worth *additionally* adding a complex but
> "realistic" test case that depends on the GCC bug, as opposed to your own
> test's simple but "unrealistic" cast to `const function_ref&&`. Here's a
> test case that I believe would have dereferenced null on GCC but would have
> worked fine on Clang—
>
> TEST(FunctionRefTest, BadCopyGCCBug) {
>
>   auto A = [] { return 1; };
>
>   function_ref<int()> W = A;
>
>   auto LW = [=]() {  // captures a data member 'const function_ref W'
>
>
...and naturally I put the comment on the wrong line. :P
The const-qualified capture happens on the *following* line.


>     return [=]() {
>
>       return W();
>
>     };
>
>   }();
>
>   auto LX = std::move(LW);  // calls function_ref's 'const&&' constructor
>
>   W = nullptr;
>
>   ASSERT_EQ(LX(), 1);
>
> }
>

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200327/8bc202b7/attachment.html>