List items
Items from the current list are shown below.
Blog
10 Sep 2023 : Day 25 #
Yesterday we were making what felt like steady progress working through errors. I can appreciate that stepping through all of these small changes doesn't make for the most entertaining of reading. But I'm afraid I don't make the rules: the gecko does.
Before we get started, I want to also take the opportunity to thank vlagged for discretely highlighting an error in my use of terminology yesterday. If you're familiar with C++ you'll surely know that double ampersand && represents an rvalue reference. Well, it turns out I'm not familiar enough! It's great to learn something important and new; as far as I'm concerned it vindicates my decision to write all this up.
Time now to get to work.
Today we we have some new errors. New errors is good: it means the previous errors are now resolved. But I'm afraid it's going to be another steady slow slog through errors again today. If that's not your thing (and I can fully appreciate it it's not) you might prefer to skip to the end.
Then we have this:
So as promised, the changes were a bit dull today, but we did move forwards, and that's what we need. Tomorrow: debugging.
As always, for other posts, check out my full Gecko Dev Diary.
Before we get started, I want to also take the opportunity to thank vlagged for discretely highlighting an error in my use of terminology yesterday. If you're familiar with C++ you'll surely know that double ampersand && represents an rvalue reference. Well, it turns out I'm not familiar enough! It's great to learn something important and new; as far as I'm concerned it vindicates my decision to write all this up.
Time now to get to work.
Today we we have some new errors. New errors is good: it means the previous errors are now resolved. But I'm afraid it's going to be another steady slow slog through errors again today. If that's not your thing (and I can fully appreciate it it's not) you might prefer to skip to the end.
312:41.03 In file included from Unified_cpp_mobile_sailfishos0.cpp:56: 312:41.03 ${PROJECT}/gecko-dev/mobile/sailfishos/embedprocess/EmbedLiteAppProcessChild.cpp: In member function ‘bool mozilla::embedlite::EmbedLiteAppProcessChild::Init (base::ProcessId, mozilla::ipc::ScopedPort)’: 312:41.04 ${PROJECT}/gecko-dev/mobile/sailfishos/embedprocess/EmbedLiteAppProcessChild.cpp:110:30: error: use of deleted function ‘mozilla::ipc::ScopedPort::ScopedPort (const mozilla::ipc::ScopedPort&)’ 312:41.04 if (!Open(aPort, aParentPid)) { 312:41.04 ^ 312:41.04 In file included from ${PROJECT}/gecko-dev/ipc/chromium/src/chrome/common/ ipc_message.h:18, 312:41.04 from ${PROJECT}/gecko-dev/ipc/chromium/src/chrome/common/ ipc_message_utils.h:22, 312:41.04 from ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ ipc/SharedMemory.h:15, 312:41.04 from ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ ipc/Shmem.h:18, 312:41.04 from ${PROJECT}/obj-build-mer-qt-xr/ipc/ipdl/ _ipdlheaders/mozilla/hal_sandbox/PHal.h:21, 312:41.04 from ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ Hal.h:13, 312:41.04 from ${PROJECT}/gecko-dev/mobile/sailfishos/EmbedLiteApp.cpp:19, 312:41.04 from Unified_cpp_mobile_sailfishos0.cpp:2: 312:41.04 ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ipc/ScopedPort.h:32:3: note: declared here 312:41.04 ScopedPort(const ScopedPort&) = delete; 312:41.04 ^~~~~~~~~~ 312:41.05 In file included from ${PROJECT}/obj-build-mer-qt-xr/ipc/ipdl/_ipdlheaders/ mozilla/embedlite/PEmbedLiteAppParent.h:16, 312:41.05 from ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ embedlite/EmbedLiteAppParent.h:9, 312:41.05 from ${PROJECT}/gecko-dev/mobile/sailfishos/embedthread/ EmbedLiteAppThreadParent.h:9, 312:41.05 from ${PROJECT}/gecko-dev/mobile/sailfishos/EmbedLiteApp.cpp:25, 312:41.05 from Unified_cpp_mobile_sailfishos0.cpp:2: 312:41.05 ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ipc/ProtocolUtils.h:447:8: note: initializing argument 1 of ‘bool mozilla::ipc::IToplevelProtocol:: Open(mozilla::ipc::ScopedPort, base::ProcessId)’ 312:41.05 bool Open(ScopedPort aPort, base::ProcessId aOtherPid); 312:41.05 ^~~~You may recall that these issues with calls to Open() relate to changes made to align with D112777. It looks like passing aPort is causing a copy that isn't allowed. We should be moving it instead:
if (!Open(std::move(aPort), aParentPid)) { [...]So happily a straightforward fix. Next we have this:
312:41.54 ${PROJECT}/gecko-dev/mobile/sailfishos/embedprocess/ EmbedLiteCompositorProcessParent.cpp At global scope: 312:41.54 ${PROJECT}/gecko-dev/mobile/sailfishos/embedprocess/ EmbedLiteCompositorProcessParent.cpp:237:80: error: invalid use of incomplete type ‘class mozilla::layers::ContentCompositorBridgeParent’ 312:41.55 FrameUniformityData* aOutData) { 312:41.55 ^ 312:41.55 In file included from ${PROJECT}/gecko-dev/mobile/sailfishos/ embedthread/EmbedLiteCompositorBridgeParent.h:14, 312:41.55 from ${PROJECT}/gecko-dev/mobile/sailfishos/ EmbedLiteApp.cpp:33, 312:41.55 from Unified_cpp_mobile_sailfishos0.cpp:2: 312:41.55 ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/layers/ CompositorBridgeParent.h:95:7 note: forward declaration of ‘class mozilla::layers::ContentCompositorBridgeParent’ 312:41.55 class ContentCompositorBridgeParent; 312:41.55 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~This is just a stupid error: I accidentally prefixed the method name with the ContentCompositorBridgeParent class when it should have been EmbedLiteCompositorProcessParent. At least that's also easy to fix then, even if I feel stupid for having made it in the first place.
Then we have this:
312:41.79 ${PROJECT}/gecko-dev/mobile/sailfishos/embedshared/EmbedLiteAppChild.cpp: In member function ‘void mozilla::embedlite::EmbedLiteAppChild::Init (mozilla::embedlite::PEmbedLiteAppChild::MessageChannel*)’: 312:41.79 ${PROJECT}/gecko-dev/mobile/sailfishos/embedshared/EmbedLiteAppChild.cpp:78:51: error: no matching function for call to ‘mozilla::embedlite:: EmbedLiteAppChild::Open(mozilla::embedlite::PEmbedLiteAppChild:: MessageChannel*&, MessageLoop*&, mozilla::ipc::Side)’ 312:41.79 Open(aParentChannel, mParentLoop, ipc::ChildSide); 312:41.80 ^This looks very similar to the issue we had with Open() in EmbedLiteCompositorProcessParent. Unfortunately there's not an obvious replacement for the existing call to Open(). The signature that we have is: bool Open(MessageChannel* aParentChannel, MessageLoop* mParentLoop, Side ipc::ChildSide); While the two candidates are the following:
bool Open(UniquePtrSo the two questions are we need to answer are:aTransport, MessageLoop* aIOLoop = 0, Side aSide = UnknownSide); bool Open(MessageChannel* aTargetChan, nsIEventTarget* aEventTarget, Side aSide);
- Can MessageChannel* be coerced into UniquePtr>Transport<?
- Can MessageLoop* be coerced into nsIEventTarget*?
So as promised, the changes were a bit dull today, but we did move forwards, and that's what we need. Tomorrow: debugging.
As always, for other posts, check out my full Gecko Dev Diary.
Comments
Uncover Disqus comments