The shared tests which access `protobuf_upb` or `protobuf_cpp`
have access to more items than the `protobuf` library itself.
This is because the former don't go through the same re-exporting based
on kernel.
I fix this by creating two test-only libraries that perform the same re-exporting
as the `protobuf` library, but with the kernel explicitly set, and changing the shared
tests to reference that instead of the inner runtime library.
This is needed to reliably test macros, where item paths are relative to the invocation,
not eagerly checked at the macro source.
PiperOrigin-RevId: 624328817
The intent of this directory would be for a layer of Rust bindings that directly map to upb semantics; Rust Protobuf runtime would be layer on top of that Rust, instead of directly on the upb C api.
PiperOrigin-RevId: 624282429
--
4b67c374d49b00860a8f285aae2e064cc58a0dc7 by Bastien Jacot-Guillarmod <bjacotg@gmail.com>:
Make `ActualT` in `Matcher` a generic type parameter.
--
7e34d847f2cda5387e55ac436ded30cc6d07bcaa by Bastien Jacot-Guillarmod <bjacotg@gmail.com>:
Accept all `Copy` type for `ActualT` instead of only reference.
PiperOrigin-RevId: 624094573
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
This will enable us to get the correct crate names for Rust gencode. The actual
reading of the mapping file in protoc happens in the followup.
PiperOrigin-RevId: 597509582
To satisfy the layering check, we need to depend on :gtest for the headers, in
addition to :gtest_main which provides the main() function.
There are a bunch of formatting changes as a side effect of this, but they
should be harmless.
PiperOrigin-RevId: 594318263
This CL implements Maps for scalar types for the C++ runtime. It's orthogonal to cl/580453646. This CL is constrained by having to force template instantiation of proto2::Map<K, V>. Put differently, a Rust protobuf::Map<K, V> implementation needs to call 'extern "C"' functions with both key and value type in the function name (e.g. __pb_rust_Map_i32_f64_get()). We use macros to generate a Map implementation for every (K,V)-pair. An alternative would have been to use vtables.
Luckily a key in a protobuf map can only be integer types, bool and string. So the number of key types is bounded by the specification, while the number of value types is not i.e. any protobuf message can be a value in a map. Given these constraints we introduce one 'MapKeyOps' trait per key type e.g. MapKeyBOOLOps or MapKeyI32Ops. These traits need to be implemented for every value type e.g. 'impl MapKeyBOOLOps for i32' will implement 'Map::<bool, i32>'. In particular the MapKeyOps traits can also be implemented for generated messages without violating the orphan rule.
This CL also contains significant changes to the UPB runtime so that both upb.rs and cpp.rs export a similar interface to simplify the implementation in map.rs and the generated code.
This CL does not yet implement the Proxied trait.
PiperOrigin-RevId: 582951914
This makes a few changes:
- It changes generated messages to reference message innards as a type in `__runtime` instead of branching on what fields should be there. That results in much less bifurcation in gencode and lets runtime-agnostic code reference raw message innards.
- It adds a generic mechanism for creating vtable-based mutators. These vtables point to thunks generated for interacting with C++ or upb fields. Right now, the design results in 2-word (msg+vtable) mutators for C++ and 3-word mutators (msg+arena+vtable) for UPB. See upb.rs for an explanation of the design options. I chose the `RawMessage+&Arena` design for mutator data as opposed to a `&MessageInner` design because it did not result in extra-indirection layout changes for message mutators. We could revisit this in the future with performance data, since this results in all field mutators being 3 words large instead of the register-friendly 2 words.
- And lastly, as a nearby change that touches on many of the same topics, it adds some extra SAFETY comments for Send/Sync in message gencode.
PiperOrigin-RevId: 559483437
This turns out to be quite of a yak shave to be able to perfectly test both kernels without having to pass extra Blaze flags.
PiperOrigin-RevId: 521850709
In this CL we're adding the barebones infrastructure to generate Rust proto messages using UPB as a backend. The API is what we call a V0, not yet production-quality, not yet rigorously designed, just something to enable parallel work.
The interesting part of switching backend between UPB and C++ will come in a followup.
PiperOrigin-RevId: 517089760
The internal design is consistent with other <lang>_proto_library rules. rust_proto_library attaches rust_proto_library_aspect on its `deps` attribute. The aspect traverses the dependency, and when it visits proto_library (detected by ProtoInfo provider) it registers 2 actions:
1) to run protoc with Rust backend to emit gencode
2) to compile the gencode using Rustc
Action (2) gets the Rust proto runtime as an input as well.
Coming in a followup is support and test coverage for proto_library.deps.
PiperOrigin-RevId: 514521285
Derek Benson
Alyssa Haroldsen
Protobuf Team Bot
Bastien Jacot-Guillarmod
Marcel Hlopko
Adam Cozzette
Jakob Buchgraber
Hong Shin
Sandy Zhang
Adrian Sadłocha
Dmitri Gribenko
Augie Fackler