[Webkit-unassigned] [Bug 139491] [GTK] Add initial database process support

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=139491

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com

--- Comment #12 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to comment #11)
> I'm not a C++11 expert, but the fact
> that when using the derived class directly, the build fails when calling
> print without using std::move for the arguments

So you can only call the function with rvalues. I think you found a bug in AsyncRequestImpl<typename... Arguments>::completeRequest. Brady, can you look at this please?

This function in the derived class in the attached test case is not right:

template <typename... Arguments>
class Printer : public PrinterBase {

void print(Arguments&&... arguments)
{
    m_printerFunction(std::forward<Arguments>(arguments)...);
}

}

Argument&&... is not a pack of forwarding/universal references (which can bind to any type) as was intended, or you would be able to call it with an lvalue. Therefore it must be a pack of rvalue references, since if it was a pack of forwarding references, Carlos wouldn't have needed the std::move to call it. So the std::forward used inside the function is useless, as it can only ever be called on rvalue references.

Now this here would be a pack of forwarding references:

template <typename... Arguments> // <-- the difference is this line
void print(Arguments&&... arguments)
{
    m_printerFunction(std::forward<Arguments>(arguments)...);
}

In the function template version, type deduction is performed on the parameters that get passed. But when it's a normal function in a template class, there is no type deduction -- the types were already specified when the class template was instantiated -- so the only reason to write the && is to force the parameters to be rvalues, which is what (I guess, almost confidently) the syntax does.

Now, at first I thought this all was unrelated to the data corruption problem, but now I think it's to blame. Here's why: AsyncRequestImpl<typename... Arguments>::completeRequest must "obviously" only be passed rvalue references and that's normally enforced at compile time as Carlos discovered, but if you call it via AsyncRequest::completeRequest, you are (possibly, and in this test case) perfect-forwarding lvalue references to it, so you wind up with lvalues being bound to rvalue references. This is the part I don't understand: how does that even compile? It seems like something that ought to be rejected at compile time, but since that's not happening, I guess it's a hole in the type system? (This is really hard to Google for.)

P.S. I think I've reread that enough times and what I wrote makes sense, but look for mistakes in my reasoning please....

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150105/cf60844b/attachment-0002.html>