1373554 - Block vendoring of rust-encoding

Status: RESOLVED FIXED

(Firefox Build System :: Mach Core, enhancement)

Description

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2025-12-29)]

In reference to https://groups.google.com/forum/#!topic/mozilla.dev.platform/80YUoZNvXYI :

We don't have third-party crates in m-c that (unconditionally) require rust-encoding. However, if the need to import such a crate arose and it wasn't feasible to make the newly-vendor crate use encoding_rs directly, in order to avoid another set of lookup tables, we should [replace] the encoding crate with a copy of https://github.com/hsivonen/encoding_rs_compat (outside third_part/rust) instead of vendoring the real rust-encoding.

Per froydnj's request on dev-platform, please make mach vendor rust refuse to vendor the real rust-encoding. (I.e. if a vendoring operation resulted in third_party/rust/encoding/ getting created, there's a reason for mach vendor rust to complain.)

Comment 1

[(not currently active) Ted Mielczarek]

This should be fairly simple to add. We already check the license of every vendored crate here:
https://dxr.mozilla.org/mozilla-central/rev/7208b6a7b11c3ed8c87a7f17c9c30a8f9583e791/python/mozbuild/mozbuild/vendor_rust.py#175

There's a list of allowed licenses above that. We could also have a list of disallowed crates there, and have a simple crate name check. (Note for any potential implementor: we'd need to do something like `package.split('-')[0]`, because crates may be vendored either as `cratename` or `cratename-version`.)

Comment 2

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2025-12-29)]

Fixed as part of bug 1986247.