Proxied is not marked as Sized yet, because ProtoStr is still dynamically sized. We will wait for clarity for the string types before marking Proxied Sized.
PiperOrigin-RevId: 627707544
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
Rename .deserialize(&mut self) method to .clear_and_parse() (by marking the .deserialized deprecated pointing at the new name, will clean up usages separately)
END_PUBLIC
Per discussion in the team chat, parse/serialize is the most typical terminology for protobuf impls, we don't have much local reason to diverge.
I'm proposing giving the 'better' name to the named ctor since I think that is the one that we expect people to reach for by default; it is generally cleaner than "new then deserialize" pattern since after a parse failure there's not any message still hanging around with implementation-defined contents, along with some other smaller ergonomics benefits.
In C++ (when exceptions aren't enabled) all constructors must be infallible, so it can't have it. In Rust there's no language idiom reason why we shouldn't have an associated fn that returns Result<Msg, ParseErr>.
PiperOrigin-RevId: 618823998
* Matches the C++ Protobuf API.
* Improves ergonomics by allowing users to provide Into, FromIterator, et. al. implementations.
* Allows owned types to be returned from functions.
PiperOrigin-RevId: 615008080
This change implements a custom Debug for messages, views and muts in the C++ kernel. Debug defers to proto2::Utf8Format.
It implements this only for the C++ kernel. We will need to pull in additional dependencies beyond minitables to implement it for UPB as well. This will be done at a later point.
PiperOrigin-RevId: 613191236
The non-string field setters can bypass the vtables already, the string setters still go through the vtable path here because its more important to let them take an `impl SettableValue` to be able to set either a &str or a &ProtoStr already.
PiperOrigin-RevId: 609705233
The actual construction of the zeroed block is now entirely safe.
This will be accessed in nearly every program using protobuf.
Using a static in .bss has much less overhead than an atomically-constructed
dynamic allocation and is far more predictable for space-constrained systems.
In the future, if dynamic allocation is kept, it should use std::sync::OnceLock
instead of the much less safe Once combined with `static mut`.
PiperOrigin-RevId: 609635555
It now uses the same prefix as other thunks needed for the proxied type,
so the RawMapThunk helper can be used for enums.
Calling it a "iter next" thunk is misleading.
It does not increment the iterator as "next" implies,
it only gets the current key/value the iterator points to.
PiperOrigin-RevId: 609527442
The purpose is to avoid duplicating the mapping of different types that are only relevant to the serializer but not to the exposed api (e.g. FIXED32 vs INT32)
Treat type=GROUP as rust-type=MESSAGE here which is all that is needed for us to support groups in the rust codegen.
The RustFieldType is parallel to the preexisting FieldDescriptor::CppType which _almost_ does what we need, but it treats Bytes and Strings as the same cpptype which Rust codegen doesn't.
PiperOrigin-RevId: 609416940
Jakob Buchgraber
Protobuf Team Bot
Derek Benson
Marcel Hlopko
Alyssa Haroldsen
Bastien Jacot-Guillarmod