Bug 236246 – Non-default constructible, non-copy-assignable types cannot be decoded with IPC::Decoder

• Component: WebKit2
• Status: RESOLVED FIXED

[Kimmo Kinnunen]

Non-default constructible types cannot be decoded with IPC::Decoder

[Kimmo Kinnunen]

Created attachment 451127 [details]
Patch

[Sam Weinig]

I am curious, what is the error you get when using a non-default constructible type?

[Kimmo Kinnunen]

It's same as this

https://godbolt.org/z/87e49njsK

#include <optional>

struct WriteReference {
    const int version;
    const int reads;
    WriteReference(int v, int r) : version(v), reads(r) { }
};
int main(int, char**) {
    std::optional<WriteReference> o { std::in_place, 1, 2 };
    std::optional<WriteReference> r { WriteReference { 1, 2 }};
    std::optional<WriteReference> r2;
    r2 = o;

    return 0;
}


ource>:12:8: error: object of type 'std::optional<WriteReference>' cannot be assigned because its copy assignment operator is implicitly deleted
    r2 = o;
       ^
/opt/compiler-explorer/clang-11.0.1/bin/../include/c++/v1/optional:767:41: note: explicitly defaulted function was implicitly deleted here
    _LIBCPP_INLINE_VISIBILITY optional& operator=(const optional&) = default;
                                        ^
/opt/compiler-explorer/clang-11.0.1/bin/../include/c++/v1/optional:587:7: note: copy assignment operator of 'optional<WriteReference>' is implicitly deleted because base class '__optional_sfinae_assign_base_t<WriteReference>' (aka '__sfinae_assign_base<(is_copy_constructible<WriteReference>::value && is_copy_assignable<WriteReference>::value), (is_move_constructible<WriteReference>::value && is_move_assignable<WriteReference>::value)>') has a deleted copy assignment operator
    , private __optional_sfinae_assign_base_t<_Tp>
      ^
/opt/compiler-explorer/clang-11.0.1/bin/../include/c++/v1/__tuple:528:25: note: 'operator=' has been explicitly marked deleted here
  __sfinae_assign_base& operator=(__sfinae_assign_base const&) = delete;
                
    ^

[Kimmo Kinnunen]

And to just avoid the discussion, I'll rename the bug to non-default constructible and non-copy-assignable. However, naturally even though the type would be copy-assignable it cannot be decoded if it is non-default constructible. This is because in order to copy over via assignment, std::optional first default-constructs something to copy over.

[Sam Weinig]

(In reply to Kimmo Kinnunen from comment #4)
> And to just avoid the discussion, I'll rename the bug to non-default
> constructible and non-copy-assignable. However, naturally even though the
> type would be copy-assignable it cannot be decoded if it is non-default
> constructible. This is because in order to copy over via assignment,
> std::optional first default-constructs something to copy over.

This all seems fine, I am more curious than anything. Would using .emplace() also resolve the issue?

[Sam Weinig]

(In reply to Sam Weinig from comment #5)
> (In reply to Kimmo Kinnunen from comment #4)
> > And to just avoid the discussion, I'll rename the bug to non-default
> > constructible and non-copy-assignable. However, naturally even though the
> > type would be copy-assignable it cannot be decoded if it is non-default
> > constructible. This is because in order to copy over via assignment,
> > std::optional first default-constructs something to copy over.
> 
> This all seems fine, I am more curious than anything. Would using .emplace()
> also resolve the issue?

And just to be clear, I am not arguing it would be better, just thinking out loud through questions.

[Kimmo Kinnunen]

(In reply to Sam Weinig from comment #5)
> This all seems fine, I am more curious than anything. Would using .emplace()
> also resolve the issue?

r2.emplace(std::move(*o)) when T is move-constructible.

[EWS]

Committed r289524 (247055@main): <https://commits.webkit.org/247055@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 451127 [details].

[Radar WebKit Bug Importer]

<rdar://problem/88742816>