On Fri, Mar 27, 2020 at 8:16 PM Arthur O'Dwyer <arthur.j.odw...@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
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
