When I originally implemented bug 1458161, this is how it was done, but
it was suggested to use a configure-time check. This turned out to not
be great, because the rust compiler changes regularly, and we don't run
the configure tests when the version changes. When people upgraded their
rust compiler to 1.27, the code subsequently failed to build because the
features were still set for the previous version they had installed.
Bug 1458161 added a rust OOM handler based on an unstable API that was
removed in 1.27, replaced with something that didn't allow to get the
failed allocation size.
Latest 1.28 nightly (2018-06-13) has
https://github.com/rust-lang/rust/pull/50880,
https://github.com/rust-lang/rust/pull/51264 and
https://github.com/rust-lang/rust/pull/51241 merged, which allow to
hook the OOM handler and get the failed allocation size again.
Because this is still an unstable API, we explicitly depend on strict
versions of rustc. We also explicitly error out if automation builds
end up using a rustc version that doesn't allow us to get the allocation
size for rust OOM, because we don't want that to happen without knowing.
Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds
uuid parsing support and exports the mp4parse_fallible feature from
mp4parse_capi.
Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally
enable mp4parse_fallible/FallibleVec.
MozReview-Commit-ID: 2HDYbL2CGgJ
Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds
uuid parsing support and exports the mp4parse_fallible feature from
mp4parse_capi.
Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally
enable mp4parse_fallible/FallibleVec.
MozReview-Commit-ID: 2HDYbL2CGgJ
OOM rust crashes are currently not identified as such in crash reports
because rust libstd handles the OOMs and panics itself.
There are unstable ways to hook into this, which unfortunately are under
active changes in rust 1.27, but we're currently on 1.24 and 1.27 is not
released yet. The APIs didn't change between 1.24 and 1.26, so it's
fine-ish to use them as long as we limit their use to those versions.
As long as the Firefox versions we ship (as opposed to downstream) use
the "right" version of rust, we're good to go.
The APIs are in their phase of stabilization, so there shouldn't be too
many variants of the code to support.
Having these definitions in two different places is silly, especially
when they must be identical. If they ever got out of sync, there would
be problems.
