[webkit-reviews] review canceled: [Bug 204331] Introduce SerializingTuple to autogenerate IPC code : [Attachment 383809] Patch

[bugzilla-daemon at webkit.org]

Alex Christensen <achristensen at apple.com> has canceled Alex Christensen
<achristensen at apple.com>'s request for review:
Bug 204331: Introduce SerializingTuple to autogenerate IPC code
https://bugs.webkit.org/show_bug.cgi?id=204331

Attachment 383809: Patch

https://bugs.webkit.org/attachment.cgi?id=383809&action=review




--- Comment #4 from Alex Christensen <achristensen at apple.com> ---
Comment on attachment 383809
  --> https://bugs.webkit.org/attachment.cgi?id=383809
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=383809&action=review

>> Source/WebKit/Shared/FrameInfoData.cpp:33
>>  void FrameInfoData::encode(IPC::Encoder& encoder) const
> 
> SO CLOSE now we just need to figure out how to get rid of these.

You can also inherit from SerializingTuple then add getters and setters, but
then you need all the member serializers to be visible when instantiating the
template in the header.  That wasn't possible without further modification to
how FrameInfoData was used in generated messages code, so I made FrameInfoData
have a SerializingTuple member.

>> Source/WebKit/Shared/FrameInfoData.cpp:-56
>> -	    return WTF::nullopt;
> 
> Before if any subtype failed to decode we'd fail the whole thing immediately
without continuing. Is that still the case?

That is still the case.

>> Source/WebKit/UIProcess/API/APIFrameInfo.cpp:43
>> +	WebKit::FrameInfoData frameInfoData {{{
> 
> Let's just throw some more curly braces in here for good luck?

It's needed to call the std::tuple constructor, then call the SerializingTuple
constructor with that std::tuple, then call the FrameInfoData constructor with
that SerializingTuple.	It can slightly be improved, but triple braces aren't
the worst thing ever.