1973598 - Evaluate using std::unique_ptr instead of mozilla::UniquePtr

Status: NEW

(Core :: MFBT, task)

Description

[[:sergesanspaille]]

std::unique_ptr provides an API close to mozilla::UniquePtr and is standard. It maybe worth switching to it for (maybe?) better implementation, leverage existing C++ knowledge etc.

Comment 1

[[:sergesanspaille]]

First experimentation on the js project:
it removes around 300 lines of code, and results in a js binary from 43240736 to 43246912 bytes (stripped), around 6kB saved while having a more standard experience and benefiting from compiler support for a standard type (e.g. wrt ownership).

Comment 2

[[:sergesanspaille]]

COnverting the whole codebase reduces libxul binary size by ~30kB. The only notable change is the rust <> C++ ffi interface, so I think it's worth pushing forward. I'll run some speedometer tests though.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Currently we have various bits of code which make assumptions about the specific implementation of a mozilla::UniquePtr<T> (such as assuming it is trivially relocatable for nsTArray, or assuming it has the exact same layout as struct { T* ptr; }; for rust-bindgen).

I expect this will run into some potential static analysis failures such as https://searchfox.org/mozilla-central/rev/ba8d4b59f46a820fc3c2f0a55c638e4f8b29bfda/build/clang-plugin/MemMoveAnnotation.h#14-59, which checks that we don't use stl types in places which assume types are trivially relocatable.

Switching to std::unique_ptr might be nice beyond those, but I expect issues like that are part of why we have not done so (though I don't remember the history).

Comment 4

[Mike Hommey [:glandium]]

I'm not sure we ever tried to move away from UniquePtr. UniquePtr itself dates back to before we even switched to C++11...