[rust] Support building and running the Rust protobuf upb kernel on wasm32-unknown-emscripten
### Motivation
While Google3 defaults `--//third_party/protobuf/rust:rust_proto_library_kernel`
to `cpp`, the open-source `protobuf` crate ships only the `upb` kernel
(`third_party/protobuf/rust/release_crates/google_protobuf/build.rs` compiles
`libupb`), and Wasm (`wasm32-unknown-emscripten`) targets that want to evaluate
or build Rust protobufs with the `upb` kernel currently fail at three build
layers plus link time.
### The 4 Blockers on `wasm32-unknown-emscripten` and Their Fixes
1. **Blaze `select()` conflict between `:use_upb_kernel` and `force_lite_runtime`**
- **Exact error (`wasm_upb_try1.log`)**:
```
ERROR: third_party/protobuf/rust/BUILD:80:13: Illegal ambiguous match on
configurable attribute "deps" in //third_party/protobuf/rust:protobuf:
//third_party/protobuf/rust:use_upb_kernel
//net/proto2/public:force_lite_runtime
Multiple matches are not allowed unless one is unambiguously more specialized.
```
- **Why `--features=-proto_force_lite_runtime` cannot work around it (`wasm_upb_try2.log`)**:
```
ERROR: The C++ toolchain '//third_party/cpptoolchains/portable_llvm/stable:cc_toolchain_wasm'
unconditionally implies feature 'proto_force_lite_runtime', which is disabled by command line
```
- **Fix (`third_party/protobuf/rust/BUILD`)**:
- `deps`: add a `:use_cpp_kernel` `config_setting`
(`rust_proto_library_kernel = "cpp"`) and a
`selects.config_setting_group(name = "force_lite_runtime_cpp_kernel",
match_all = [":use_cpp_kernel", "//net/proto2/public:force_lite_runtime"])`,
replacing `//net/proto2/public:force_lite_runtime` in the `deps` `select()`.
- `rustc_flags` of `:protobuf` and `:protobuf_lite`: split into two
concatenated, orthogonal `select()`s (kernel: `--cfg=upb_kernel` /
`--cfg=cpp_kernel`; `//net/proto2/public:force_lite_runtime`:
`--cfg=lite_runtime`). cpp and cpp + force-lite get exactly the same flags
as before; upb + force-lite now also gets `--cfg=lite_runtime`, gating off the
`not(lite_runtime)` items in `protobuf.rs` (so it reduces to
`pub use protobuf_lite::*`) to match the lite gencode that `aspects.bzl`
emits under `proto_force_lite_runtime` for both kernels.
2. **`linkme::distributed_slice` unsupported on `target_os = "emscripten"`**
- **Exact error (`wasm_upb_try3.log`)**:
```
error: distributed_slice is not implemented for this platform
--> third_party/protobuf/rust/upb_kernel/extension.rs:40:1
|
40 | #[linkme::distributed_slice]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0425]: cannot find value `LINKME_START_EXTENSIONS` in this scope
error[E0425]: cannot find value `LINKME_STOP_EXTENSIONS` in this scope
error[E0425]: cannot find value `LINKME_DUPCHECK_START_EXTENSIONS` in this scope
error[E0425]: cannot find value `LINKME_DUPCHECK_STOP_EXTENSIONS` in this scope
```
- **Root cause**: `linkme` 0.3.35 has no `target_os = "emscripten"` backend
(the per-OS `link_section` `cfg_attr` list in `third_party/rust/linkme_impl/v0_3/src/declaration.rs`), and
cannot be extended directly: on Wasm targets (`is_like_wasm`), `rustc` emits
`#[link_section]` statics as non-addressable Wasm custom sections, with a
hardcoded exception only for `.init_array*` sections
(`rustc_codegen_llvm/src/consts.rs:545-560`).
- **Fix (`third_party/protobuf/rust/upb_kernel/extension.rs`)**: Gate
`#[linkme::distributed_slice]` on `#[cfg(not(target_os = "emscripten"))]`. On
`#[cfg(target_os = "emscripten")]`:
- Provide an empty `pub static EXTENSIONS: linkme::DistributedSlice<[LazyLock<MiniTableExtensionInitPtr>]>`
in the value namespace so generated `#[linkme::distributed_slice($pbr$::EXTENSIONS)]`
attributes continue to type-check without modifying `protoc`'s Rust code
generator (`compiler/rust/extension.cc`).
- Export `#[macro_export] macro_rules! __protobuf_upb_emscripten_extensions`
re-exported as `pub use __protobuf_upb_emscripten_extensions as EXTENSIONS;`
in the macro namespace. `#[linkme::distributed_slice($pbr$::EXTENSIONS)]`
expands to `$pbr$::EXTENSIONS! { #![linkme_macro = ...] pub static ... }`
(`third_party/rust/linkme_impl/v0_3/src/element.rs`, `expand`), which
our macro intercepts to emit the extension's `LazyLock<MiniTableExtensionInitPtr>`
static alongside a `#[used] #[unsafe(link_section = ".init_array.101")]`
constructor that pushes `&'static LazyLock<MiniTableExtensionInitPtr>` into
`EMSCRIPTEN_EXTENSIONS` during `__wasm_call_ctors` (`_initialize`).
- In `generated_extension_registry()`, iterate `EMSCRIPTEN_EXTENSIONS` and
register each extension in the `upb_ExtensionRegistry`.
3. **Unstable `core::arch::global_asm!` on `wasm32`**
- **Exact error (`wasm_upb_try3.log`)**:
```
error[E0658]: inline assembly is not stable yet on this architecture
--> third_party/protobuf/rust/upb_kernel/extension.rs:44:1
|
44 | / core::arch::global_asm!(
... |
55 | | );
| |_^
```
- **Root cause**: `wasm32-unknown-emscripten` sets `target_family = "unix"`,
so it matches the ELF sentinel `global_asm!` gate.
- **Fix (`third_party/protobuf/rust/upb_kernel/extension.rs`)**: Add
`not(target_os = "emscripten")` to both `global_asm!` gates (head already
excludes `target_vendor = "apple"`).
4. **Emscripten link failure when `longjmp = "off"`**
- **Exact error (`wasm_upb_try4.log`)**:
```
emcc: error: '.../wasm-ld ...':
wasm-ld: error: ...: undefined symbol: __wasm_longjmp
error: longjmp support was disabled (SUPPORT_LONGJMP=0), but it is required by the code (either set SUPPORT_LONGJMP=1, or remove uses of it in the project)
```
- **Root cause**: `upb`'s wire decoder (`upb_Decode`), wire encoder
(`upb_Encode`), and MiniTable builder (`upb_MiniTable_Build`) use
`UPB_SETJMP` / `UPB_LONGJMP` (`setjmp` / `longjmp` in
`third_party/upb/upb/port/def.inc`) for error unwinding.
- **Requirement (documented in `third_party/protobuf/rust/test/upb/BUILD` and
`wasm_extension_test.rs`)**: `wasm_cc_binary` targets linking `upb` must set
`longjmp = "wasm"` (Wasm Exception Handling instructions, required when
`standalone = True`), use the default `longjmp = "emscripten"`, or compile
`upb` with `--copt=-DWASM_WAMR=1` (which replaces `UPB_SETJMP`/`UPB_LONGJMP`
with `0`/`abort()`).
### Caveats
- **Unreferenced extension-only crates on `wasm32`**: On `wasm32`, `rustc`
sets `has_symbols_obj = false` (`Target::object_architecture` returns `None`,
so `add_linked_symbol_object` in `rustc_codegen_ssa/src/back/link.rs` emits no
`symbols.o` table of `#[used]` statics into `.rlib` archives). Consequently,
when `wasm-ld` links an `.rlib` archive without `--whole-archive`, an object
file containing an `.init_array` extension constructor is extracted only if at
least one symbol from that codegen unit is referenced by the binary. Extensions
in crates that are never referenced by any code path will not have their
`.init_array` constructors linked on Wasm (whereas native `linkme` retains them
via `symbols.o`).
- **Constructor priority `.init_array.101` + late-registration check**:
Bare `.init_array` entries run at default priority `65535`. If another static
constructor at default priority parses a message before all extension
constructors have run, `generated_extension_registry()` would freeze the
`LazyLock` registry early. The macro therefore places constructors in
`.init_array.101`, and `__emscripten_register_extension` asserts via
`debug_assert!` that `EMSCRIPTEN_REGISTRY_BUILT` is still `false`.
- **Copybara compatibility**: `load("//third_party/bazel_skylib/lib:selects.bzl", "selects")`
in `third_party/protobuf/rust/BUILD` and the Google3-only Wasm targets/loads in
`third_party/protobuf/rust/test/upb/BUILD` (`wasm_cc_binary`, `build_test`,
`rust_binary`) are annotated with `# copybara:strip` /
`# copybara:strip_begin` / `# copybara:strip_end_and_replace_begin` so OSS
Bazel exports remain clean.
- **Second linkme slice (`EXTENSION_MINI_TABLE_TO_DEF_INITS`, reflection)**: both
linkme slices (`EXTENSIONS` and `EXTENSION_MINI_TABLE_TO_DEF_INITS`) are gated
off on Emscripten; `EXTENSION_MINI_TABLE_TO_DEF_INITS` elements are registered
from `.init_array.101` constructors like `EXTENSIONS`, and `def_pool.rs`
`load_all_extensions` reads those registrations on Emscripten.
- **linkme internals**: the Emscripten path relies on `#[doc(hidden)]
linkme::DistributedSlice::private_new` and linkme_impl's `#![linkme_macro]` /
`#![linkme_sort_key]` expansion grammar (verified against 0.3.35), so the OSS
crate pins `linkme = "=0.3.35"` in
`rust/release_crates/google_protobuf/Cargo-template.toml` (linkme itself pins
`linkme-impl = "=0.3.35"` for the same reason). The exact pin applies to
every OSS user, so a dependency graph that needs linkme >= 0.3.36 will not
resolve until the Emscripten path is re-verified and the pin bumped; this is
a deliberate trade-off.
- **Test coverage**: on TAP, `wasm_extension_test` runs natively (the
`target_os = "emscripten"` code is compiled out) and `wasm_extension_build_test`
only compiles and links `:wasm_extension_wasm`. Executing the Emscripten
registration path (`node .../wasm_extension_bin.js`) and building
`//third_party/protobuf/rust:protobuf` with upb on wasm32 are manual steps
(see Tests Run).
- **Exported constructor globals on Emscripten**: On `wasm32-unknown-emscripten`,
`#[used]` on `static __PROTOBUF_EXTENSION_CTOR` causes LLVM's Wasm backend to
set `WASM_SYMBOL_EXPORTED`, so `wasm-ld`/`emcc` emits a Wasm global and export
table entry per registered extension. Eliminate-at-compile-time retention
without exporting would require `#[used(compiler)]` (unstable) or a `protoc`
Rust generator change to emit one registration call per crate instead of per
extension.
PiperOrigin-RevId: 1015838072
Copyright 2008 Google LLC
Protocol Buffers (a.k.a., protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. You can learn more about it in protobuf's documentation.
This README file contains protobuf installation instructions. To install protobuf, you need to install the protocol compiler (used to compile .proto files) and the protobuf runtime for your chosen programming language.
Most users will find working from supported releases to be the easiest path.
If you choose to work from the head revision of the main branch your build will occasionally be broken by source-incompatible changes and insufficiently-tested (and therefore broken) behavior.
If you are using C++ or otherwise need to build protobuf from source as a part of your project, you should pin to a release commit on a release branch.
This is because even release branches can experience some instability in between release commits.
Protobuf supports Bzlmod with Bazel 8 +. Users should specify a dependency on protobuf in their MODULE.bazel file as follows.
bazel_dep(name = "protobuf", version = <VERSION>)
Users can optionally override the repo name, such as for compatibility with WORKSPACE.
bazel_dep(name = "protobuf", version = <VERSION>, repo_name = "com_google_protobuf")
Users can also add the following to their legacy WORKSPACE file.
Note that with the release of 30.x there are a few more load statements to properly set up rules_java and rules_python.
http_archive(
name = "com_google_protobuf",
strip_prefix = "protobuf-VERSION",
sha256 = ...,
url = ...,
)
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()
load("@rules_java//java:rules_java_deps.bzl", "rules_java_dependencies")
rules_java_dependencies()
load("@rules_java//java:repositories.bzl", "rules_java_toolchains")
rules_java_toolchains()
load("@rules_python//python:repositories.bzl", "py_repositories")
py_repositories()
The protobuf compiler is written in C++. If you are using C++, please follow the C++ Installation Instructions to install protoc along with the C++ runtime.
For non-C++ users, the simplest way to install the protocol compiler is to download a pre-built binary from our GitHub release page.
In the downloads section of each release, you can find pre-built binaries in zip packages: protoc-$VERSION-$PLATFORM.zip. It contains the protoc binary as well as a set of standard .proto files distributed along with protobuf.
If you are looking for an old version that is not available in the release page, check out the Maven repository.
These pre-built binaries are only provided for released versions. If you want to use the github main version at HEAD, or you need to modify protobuf code, or you are using C++, it's recommended to build your own protoc binary from source.
If you would like to build protoc binary from source, see the C++ Installation Instructions.
Protobuf supports several different programming languages. For each programming language, you can find instructions in the corresponding source directory about how to install protobuf runtime for that specific language:
| Language | Source |
|---|---|
| C++ (include C++ runtime and protoc) | src |
| Java | java |
| Python | python |
| Objective-C | objectivec |
| C# | csharp |
| Ruby | ruby |
| Go | protocolbuffers/protobuf-go |
| PHP | php |
| Dart | dart-lang/protobuf |
| JavaScript | protocolbuffers/protobuf-javascript |
The best way to learn how to use protobuf is to follow the tutorials in our developer guide.
If you want to learn from code examples, take a look at the examples in the examples directory.
The complete documentation is available at the Protocol Buffers doc site.
Read about our version support policy to stay current on support timeframes for the language libraries.
To be alerted to upcoming changes in Protocol Buffers and connect with protobuf developers and users, join the Google Group.