The .proto.h is not emitted by default from the cc generator in OSS, rather than try to force it to emit we can just use the .pb.h
PiperOrigin-RevId: 676464651
It's possible to operate on a `Map<K, V>` without necessarily knowing at
compile time what `K` and `V` are. The way to do this is by using
`UntypedMapBase`, which `proto2::Map` inherits from. However, to do anything
useful with the map you need two important bits of information: the size of the
map entry, which is represented as a `std::pair<K, V>`, and the offset of the
value within that. These are combined together into the `MapNodeSizeInfoT`
type.
For Rust to wrap C++ maps, we currently need to store in C++ generated code an
array of `MapNodeSizeInfoT` for each message type. The Rust code has to call
into C++ to ask for the appropriate `MapNodeSizeInfoT` and then pass that back
into C++ for map operations.
Dealing with these message-specific constants is pretty awkward, so this CL
introduces a way around that. By making each message's alignment available
through the `MessageLite*` interface, we make it possible to compute the
necessary size info on the fly, instead of requiring the Rust implementation to
store it in generated code. Luckily the existing padding inside
`MessageCreator` provided enough room to store the alignment. Although this
change is mostly for the benefit of Rust, it doesn't cost C++ anything.
This change doesn't actually simplify the Rust implementation yet, but I will
leave that for a follow-up.
PiperOrigin-RevId: 676456011
`UntypedMapIterator::next_unchecked` currently expects to be passed a pointer
to a C++ function that it can use to dereference an iterator. However, this is
awkward because it's not natural for this C++ function to have the same
signature for every map type. Maps with a message as value need a
`MapNodeSizeInfo`, but other map types do not. We are working around this by
sometimes passing an ignored placeholder constant, but this is messy.
This CL replaces the `extern "C"` functions with closures. This way, we can
capture the `MapNodeSizeInfo` in the closure in cases where we need it, but
otherwise we no longer need to pass around placeholder values.
(Note: `MapNodeSizeInfo` is going away soon, but this is still relevant because
it will likely need to be replaced by a message default instance pointer.)
PiperOrigin-RevId: 676438640
Maps behave in a very interesting way if they are set to be implicit-presence
fields.
They present the possibility that the key or value (or both) can be the default
zero value. When that happens, access to the key or the value is unaffected. In
this case, presence is a bit of a meaningless concept. Zero keys are valid as
map indices, and if a map entry is set to zero, it just always exists.
Reflection is a little weird too.
- If you do reflection on a normal integer field and ask if a zero-valued field
exists, it will tell you that it doesn't exist. This is consistent with what
"implicit presence" means.
- If you do reflection on a zero integer field that happens to be a map key, it
will tell you that it exists. Fetching the value of map[0] is equally valid.
(Note that this is not exactly *intended*, but it's just hard to change... and
this implementation results in simpler gencode.)
I'm adding unit tests in no_field_presence_test to cover this quirk.
PiperOrigin-RevId: 676268392
This is a very narrow edge case where touching a packed extension via generated APIs first, and then doing so reflectively will trigger a DCHECK. Otherwise, reflective APIs will work but not use packed encoding for the extension. This was likely a pre-existing bug dating back to proto3, where it would only be visible on custom options (the only extensions allowed in proto3).
To help qualify this and uncover similar issues, unittest.proto was migrated to editions. This turned up some other minor issues in DebugString and python.
PiperOrigin-RevId: 675785611
This can be used by dynamic messages to validate enums instead of going through
reflection.
This removes one of the few cases where dynamic messages have to fall back to
reflection during table-driven parsing.
PiperOrigin-RevId: 675630939
This CL fixes an unnecessary string copy. `Message::GetTypeName()` always
returns a copy, but we can avoid this by relying on `Descriptor::full_name()`
instead.
PiperOrigin-RevId: 675237607
The logic to create new elements in `RepeatedPtrField` was spread across an assorted collection of specializations of `GenericTypeHandler`, individual `GenericTypeHandler` static functions, and external member and non-member functions, all living in multiple sources. Now all that logic is concentrated in three symmetric `GenericTypeHandler` specializations.
PiperOrigin-RevId: 674064544
I realized that as long as we implement `UpbTypeConversions` for enums, we can
easily get the blanket implementation for messages to work for enums as well.
Luckily the blanket implementation also happens to work for non-generated
types, so this gets us down to just one ProxiedInMapValue implementation for
upb.
PiperOrigin-RevId: 673927343
This reduces the total number of instantiations and reduces binary size costs.
It puts an hard upper bound on the total number of instantiations of the template.
PiperOrigin-RevId: 673452657
The `retention` and `target` options have been functional for a long time, so
we can delete these stale comments saying that they do not work yet.
PiperOrigin-RevId: 673401292
- Add overloads that take `absl::Cord` and `std::string&&` as inputs, putting
the burden in the implementation instead of users.
- Hide the APIs that return `std::string*` when the breaking change is
enabled (via `-DPROTOBUF_TEMPORARY_ENABLE_STRING_VIEW_RETURN_TYPE`)....
PiperOrigin-RevId: 673397581
`ClassData`. This reduces code size bloat and runtime costs when using the
custom vtable. It has no significant change for normal mode.
PiperOrigin-RevId: 673010897
This enables enforcement of lifetime specifications on individual enum values for features. It will allow us to add new values to existing features, as well as deprecate/and remove existing values. By default, each value will be scoped to the lifetime spec of its corresponding feature field. However, individual lifetime boundaries can be overridden at the value-level for finer grained control.
In the near-term, this will allow us to deprecate/remove required field presence, and add a stricter utf8 validation feature.
PiperOrigin-RevId: 672710484
* `GenericTypeHandler` used to be forward-declared in message_lite.h and unncessarily friended by `MessageLite`, which was its only use in that source. repeated_ptr_field.h relied on that forward declaration being there, and fully defined `GenericTypeHandler` below the first use.
* `StringPieceField` was forward-declared, and now IWYU'ed.
PiperOrigin-RevId: 672686570
* s/Handler/TypeHandler/g.
* Consistently use aliased `Type` throughout the `GenericTypeHandler` specializations. This makes visual diffing between them easier.
PiperOrigin-RevId: 672665545
Protobuf Team Bot
Derek Benson
Protobuf Team Bot
Adam Cozzette
Tony Liao
Evan Brown
Mike Kruskal
Zoey Greer
liqipeng