protobuf

Protocol Buffers - Google's data interchange format (grpc依赖) https://developers.google.com/protocol-buffers/

Adam Cozzette 6ab302d3a3 Rust: cut down on the amount of generated C++ code needed for maps With the C++ kernel for Rust, we currently need to generate quite a few C++ thunks for operations on map fields. For each message we generate, we generate these thunks for all possible map types that could have that message as a value. These operations are for things such as insertion, removal, clearing, iterating, etc. The reason we do this is that templated types don't play well with FFI, so we effectively need separate FFI endpoints for every possible combination of key and value types used (or even potentially used) as a map field. This CL fixes the problem by replacing the generated thunks with functions in the runtime that can operate on `proto2::MessageLite*` without needing to care about the specific message type. The way it works is that we implement the operations using either `UntypedMapBase` (the base class of all map types, which knows nothing about the key and value types) or `KeyMapBase`, which knows the key type but not the value type. I roughly followed the example of the table-driven parser, which has a similar problem of needing to operate generically on maps without having access to the concrete types. I removed 54 thunks per message (that's 6 key types times 9 operations per key), but had to add two new thunks per message: - The `size_info` thunk looks up the `MapNodeSizeInfoT`, which is stored in a small constant table. The important thing here is an offset indicating where to look for the value in each map entry. This offset can be different for every pair of key and value types, but we can safely assume that the result does not depend on the signedness of the key. As a result we only need to store four entries per message: one each for i32, i64, bool, and string. - The `placement_new` thunk move-constructs a message in place. We need this to be able to efficiently implement map insertion. There are two big things that this CL does not address yet but which I plan to follow up on: - Enums still generate many map-related C++ thunks that could be replaced with a common implementation. This should actually be much easier to handle than messages, because every enum has the same representation as an i32. - We still generate six `ProxiedInMapValue` implementations for every message, but it should be possible to replace these with a blanket implementation that works for all message types. PiperOrigin-RevId: 657681421		4 months ago
..
BUILD	Rust: cut down on the amount of generated C++ code needed for maps	4 months ago
debug.cc	Enable MessageLite::DebugString to use Message::DebugString where possible.	5 months ago
debug.h	Enable MessageLite::DebugString to use Message::DebugString where possible.	5 months ago
map.cc	Rust: cut down on the amount of generated C++ code needed for maps	4 months ago
map.h	Rust: cut down on the amount of generated C++ code needed for maps	4 months ago
repeated.cc	Rust protobuf: fix memory leaks	5 months ago
rust_alloc_for_cpp_api.h	Change to proto2_rust C prefix and proto2::rust C++ namespace	5 months ago
rust_alloc_for_cpp_api.rs	Change to proto2_rust C prefix and proto2::rust C++ namespace	5 months ago
serialized_data.h	Change to proto2_rust C prefix and proto2::rust C++ namespace	5 months ago
strings.cc	Use a std::string as the backing string & bytes type in the C++ kernel. This will allow us to move a ProtoString/Bytes to a message accessor without copying. This change only touches the C++ kernel, as the UPB kernel already uses the native arena-allocated UPB string type for ProtoString/Bytes.	5 months ago
strings.h	Use a std::string as the backing string & bytes type in the C++ kernel. This will allow us to move a ProtoString/Bytes to a message accessor without copying. This change only touches the C++ kernel, as the UPB kernel already uses the native arena-allocated UPB string type for ProtoString/Bytes.	5 months ago