This is the final CL (part 4 of 4) in the ProxiedWithPresence chain.
In the past, we had returned Mut directly for the `_mut` accessors.
This was a temporary engagement in order to get the other submsg machinery checked in.
As we prep for the finalization of v0.6, we can finally conform to the rest of the `_mut` getters.
$field$_mut now correctly returns $pb$::FieldEntry<'_, $msg_type$> as a part of this.
All test callsites have been updated to `.or_default` in order to test the mutational pathway as before.
PiperOrigin-RevId: 602739186
Before this change if a field type was defined in a imported .proto file then our codegen would not generate the field. After this change such fields are correctly generated (see tests). This change is rather trivial as all the supporting infra has been implemented as part of the .proto -> crate mapping CLs.
PiperOrigin-RevId: 601443383
Part 3 of 4 (added a stage).
The getter and mut_getter bifurcate based on the kernel.
upb returns Option<RawMessage>, while cpp returns the RawMessage.
This means that we can't have a unified MessageVTable in vtable.rs, so we've split these out in {upb.rs and cpp.rs}.
$field$_entry is now prepped and populated for the $field$_mut swappage in the following CL.
PiperOrigin-RevId: 601230880
Stage 2 of 3.
Fleshed out the bodies required by the aforementioned contracts above.
We create MessageVTable and utilize the `unsafe fns` directly in `message.cc` -- a departure from PrimitiveVTables.
In the final followup CL, we will perform the field_entry swapover and update all unit tests.
PiperOrigin-RevId: 600567890
We want to return $pb$::FieldEntry<'_, $msg_type$> for msg_mut accessors as opposed to the current state (returning $Msg$Mut directly).
In this CL, we pave the way to implementing field entry returns.
We introduce { MessagePresentMutData, MessageAbsentMutData } and impl { ProxiedWithRawVTable, ProxiedWithRawOptionalVTable }. I initially tried a blanket impl approach, but it collided with the already existing PrimitiveVTable constructs; perhaps worth revisiting post 0.6.
In a followup, we'll flesh out the bodies. Lastly, we'll perform the swapover by
replacing $field$_mut with $field$_entry, updating all related tests.
PiperOrigin-RevId: 599282850
- Only prepend r# to fields when needed instead of always
- Append '__mangled_because_symbol_is_a_rust_raw_identifier' to names like 'Self' which can't be used legally even with an r# prefix
Also use the same check to prepend r# on:
- Message names (eg `message Self {}`)
- oneof names
- oneof case names
- enum names
- enum case names
- module names (e.g. 'package google.type')
PiperOrigin-RevId: 599153141
We now support fields with bytes as map values e.g. map<i32, bytes>. The implementation for the C++ runtime was straightforward. The majority of the changes in this CL are about the UPB runtime. In UPB, when we insert Rust bytes/string into the map we need to first copy the bytes onto the maps arena. To support this I have rewritten the macro that implements the ProxiedInMapValue types. I refactored the functionality to convert between UPB and Rust types into the 'UpbTypeConversions' trait. This trait has a function 'to_message_value_if_required' which does the copying for bytes and strings.
PiperOrigin-RevId: 599118416
This adds private methods of:
-- .raw_msg() to Msg+MsgMut+MsgView
-- .raw_arena() to Msg+MsgMut [upb kernel only]
And updates the accessors to use the self.raw_msg() / self.raw_arena().
A couple more things will need to be changed before the accessors can be verbatim reused in Msg/MsgView/MsgMut which will be mailed separately.
PiperOrigin-RevId: 598869392
- ProxiedInMapValue is defined in maps.rs, and no longer in the runtime files {upb, cpp}.rs.
- ProxiedInMapValue's methods accept and return Proxied types.
- InnerMapMut no longer has any generic type parameters.
- Through this refactoring the Map type is no longer a ZST. Creating a new map is now as simple as `Map::new()`.
PiperOrigin-RevId: 597765165
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
When we implement Deref for RepeatedMut we cast it to a RepeatedView. The safety comments state that this is sound because both RepeatdView and RepeatedMut are repr(transparent) over InnerRepeatedMut. However, this has no longer been true after a recent change. RepeatedView and RepeatedMut had different layouts.
This change fixes the soundness issue by type casting the RawRepeatedField of a RepeatedMut to a RepeatedView. This is sound because RepeatedReview is repr(transparent) over RawRepeatedField.
PiperOrigin-RevId: 597488476
If this took a &self there were holes in thread and memory safety, because it's allowed to get multiple &MsgMuts (but only &mut MsgMuts).
PiperOrigin-RevId: 596991263
This change is a pure refactoring and simplification of the code. We replace all MapsWith<TYPE>KeyOps traits through a single generic ProxiedInMapValue<K> trait. Through connecting the runtime maps implementation with Proxied the code gets a lot simpler e.g. we can use View<T> instead of hardcoding the concrete type behind it.
I also expect this change to be beneficial for the gencode. In a subsequent CL we'll implement message values for maps. After this change we'll only have to implement a single trait, while before we had to implement num(key types) many traits.
PiperOrigin-RevId: 596562909
This check enforces that each C++ build target has the correct dependencies for
all headers that it includes. We have many targets that were not correct with
respect to this check, so I fixed them up.
I also cleaned up the C++ targets related to the well-known types. I created a
cc_proto_library() target for each one and removed the :wkt_cc_protos target,
since this was necessary to satisfy the layering check. I deleted the
//src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt,
because the distinction between the :protobuf and :protobuf_nowkt targets was
not really correct. Neither one exposed the headers for the well-known types in
a way that was valid with respect to the layering check, and the idea of
bundling all the well-known types together is not idiomatic in Bazel anyway.
This is a breaking change, because the //:protobuf target no longer bundles the
well-known types. From now on they should be accessed through the new
//:*_cc_proto aliases in our top-level package.
I renamed the :port_def target to :port, which simplifies things a bit by
matching our internal name.
The original motivation for this change was that to move utf8_range onto our CI
infrastructure, we needed to make its dependency rules_fuzzing compatible with
Bazel 6. The rules_fuzzing project builds with the layering check, and I found
that the process of upgrading it to Bazel 6 made it take a dependency on
protobuf, which caused it to break due to layering violations. I was able to
work around this, but it would still be nice to comply with the layering check
so that we don't have to worry about this kind of thing in the future.
PiperOrigin-RevId: 595516736
For the cpp runtime, call the `Message::CopyFrom` method.
For the upb runtime, expose the message `MiniTable` and call `upb_Message_DeepCopy`.
PiperOrigin-RevId: 595166276
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
Hong Shin
Marcel Hlopko
Jakob Buchgraber
Alyssa Haroldsen
Kevin King
Protobuf Team Bot
Bastien Jacot-Guillarmod
Adam Cozzette