Bug 245044 - no viable conversion from returned value of type 'tuple<IPC::Attachment &&>'
Summary: no viable conversion from returned value of type 'tuple<IPC::Attachment &&>'
Status: RESOLVED DUPLICATE of bug 246149
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Other
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-11 05:04 PDT by Antoine Jacoutot
Modified: 2022-12-13 05:26 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Jacoutot 2022-09-11 05:04:21 PDT
Hi.

Trying to build release 2.37.91 or HEAD (as of today) on:

$ uname -mrsv                                                  
OpenBSD 7.2 GENERIC.MP#719 amd64
$ c++ --version                                                
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.2
Thread model: posix
InstalledDir: /usr/bin

... with libc++ 13.0.0.

I am running into the following error:

<...>/__/__/DerivedSources/WebKit/WebInspectorUIProxyMessageReceiver.cpp.o -MF Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/WebInspectorUIProxyMessageReceiver.cpp.o.d -o Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/WebInspectorUIProxyMessageReceiver.cpp.o -c /hack/objdirs/pobj/webkitgtk40-2.37.91/build-amd64/DerivedSources/WebKit/WebInspectorUIProxyMessageReceiver.cpp
In file included from <built-in>:1:
In file included from /hack/objdirs/pobj/webkitgtk40-2.37.91/webkitgtk-2.37.91/Source/WebKit/WebKit2Prefix.h:72:
In file included from /usr/include/c++/v1/algorithm:653:
In file included from /usr/include/c++/v1/functional:495:
In file included from /usr/include/c++/v1/__functional/bind_front.h:14:
In file included from /usr/include/c++/v1/__functional/perfect_forward.h:14:
/usr/include/c++/v1/tuple:1505:12: error: no viable conversion from returned value of type 'tuple<IPC::Attachment &&>' to function return type 'tuple<IPC::Attachment>'
    return __tuple_cat<tuple<>, __tuple_indices<>,
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/hack/objdirs/pobj/webkitgtk40-2.37.91/webkitgtk-2.37.91/Source/WebKit/Platform/IPC/ArgumentCoders.h:532:21: note: in instantiation of function template specialization 'std::tuple_cat<std::tuple<IPC::Attachment>, std::tuple<>>' requested here
        return std::tuple_cat(std::make_tuple(WTFMove(*optional)), WTFMove(*remainder));
                    ^
/hack/objdirs/pobj/webkitgtk40-2.37.91/webkitgtk-2.37.91/Source/WebKit/Platform/IPC/ArgumentCoders.h:555:43: note: in instantiation of function template specialization 'IPC::TupleDecoder<IPC::Attachment>::decode<IPC::Decoder>' requested here
        return TupleDecoder<Elements...>::decode(decoder);
                                          ^
/hack/objdirs/pobj/webkitgtk40-2.37.91/webkitgtk-2.37.91/Source/WebKit/Platform/IPC/Decoder.h:126:40: note: in instantiation of function template specialization 'IPC::ArgumentCoder<std::tuple<IPC::Attachment>>::decode<IPC::Decoder>' requested here
            std::optional<T> t { Impl::decode(*this) };
                                       ^

Might have something to do with our libc++ version but as this point, I could use some help.
Thanks a lot.
Comment 1 Adrian Perez 2022-09-12 01:38:38 PDT
I have run into into what looks like exactly the same build error when trying
to update WPE-Android to 2.37.91 (https://github.com/Igalia/cerbero/pull/27
Currently we are using NDK r23b, which ships Clang/LLVM 12. The template
specialization looks a bit iffy so maybe we'll need to look into that anyway.
Comment 2 Adrian Perez 2022-09-14 03:45:22 PDT
I can reproduce this configuring with Clang/libc++ 14.0.6, so the issue
is still there regardless of using newer versions. In order to reproduce
on Linux, use:

  CC=clang CXX=clang++ CXXFLAGS=-stdlib=libc++ \
      cmake -S. -Bbuild-libcxx -DPORT=GTK -GNinja
  ninja -Cbuild-libcxx
Comment 3 Michael Catanzaro 2022-09-14 06:18:57 PDT
I think this is caused by 249548@main.

(How do I know this? Because Leslie Zhai said so in https://github.com/WebKit/WebKit/pull/3908#issuecomment-1235025317.)
Comment 4 Zan Dobersek 2022-09-14 07:24:21 PDT
(In reply to Adrian Perez from comment #2)
> I can reproduce this configuring with Clang/libc++ 14.0.6, so the issue
> is still there regardless of using newer versions. In order to reproduce
> on Linux, use:
> 
>   CC=clang CXX=clang++ CXXFLAGS=-stdlib=libc++ \
>       cmake -S. -Bbuild-libcxx -DPORT=GTK -GNinja
>   ninja -Cbuild-libcxx

Not achievable on Debian Unstable since libc++ depends on a libunwind package that's in conflict with another libunwind package that's dependency of libgstreamer-plugins-base1.0-dev, without which the configuration or build won't succeed.
Comment 5 Leslie Zhai 2022-09-14 17:23:33 PDT
(In reply to Michael Catanzaro from comment #3)
> I think this is caused by 249548@main.
> 
> (How do I know this? Because Leslie Zhai said so in
> https://github.com/WebKit/WebKit/pull/3908#issuecomment-1235025317.)

Yes, it is reproducible for LoongArch64 when using LLVM libcxx, so we just revert the commit:  [WK2] Simplify IPC encoding, decoding of tuples  https://github.com/WebKit/WebKit/commit/34daeac7dc0fb6f1d9421c5c6c8cdf92cdc0abc5

Thanks,
Leslie Zhai
Comment 6 Zan Dobersek 2022-10-08 00:32:24 PDT
Fixed by removing concatenation in #246149
https://github.com/WebKit/WebKit/pull/5083
Comment 7 Adrian Perez 2022-12-13 05:26:41 PST
(In reply to Zan Dobersek from comment #6)
> Fixed by removing concatenation in #246149
> https://github.com/WebKit/WebKit/pull/5083

Antoine, I see that the 2.38.2 release (which includes this patch) is
available in the OpenBSD ports tree: https://openports.se/www/webkitgtk4
so it seems this issue has indeed been fixed for you. Therefore I am going
to close this as a duplicate -- please reopen the issue if I am wrong and
there is still something we would need to fix in this regard :)

*** This bug has been marked as a duplicate of bug 246149 ***