Message fields can never have implicit presence, but we have logic in
ClearField that deallocates the message field and reassigns nullptr if the
field is a "proto3" field.
This snippet is the remnants of an old implementation of message field
reflection when proto3 was first introduced (when the initial idea is to use
open structs for everything). During implementation however, we ended up
preserving explicit presence behavior for message fields.
PiperOrigin-RevId: 691199008
Note:
This change primarily affects debug + ASAN builds using protobuf arenas.
If this change causes a crash in your debug build, it probably means that
there is a use-after-free bug in your program. This change has already been
implemented and battle-tested within Google for some time.
Oneof messages on the regular heap should not be affected because the memory
they hold are already deleted. Users will already see use-after-free errors
if they attempt to access heap-allocated oneof messages after calling Clear().
When a protobuf message is cleared, all raw pointers should be invalidated
because undefined things may happen to any of the fields pointed to by
mutable_foo() APIs. While destructors may not necessarily be invoked, Clear()
should be considered a pointer invalidation event.
#test-continuous
PiperOrigin-RevId: 689569669
are enabled.
This makes the function a drop-in replacement for `dynamic_cast` when the user
is expecting exceptions to be thrown.
PiperOrigin-RevId: 689419852
By just checking for upper-cased characters, rather than digits and lower-cased characters, we have to perform fewer comparisons.
This should be safe because absl::AsciiStrToLower only operates on upper-case characters.
PiperOrigin-RevId: 688453016
Clarifies that reordering `enum` fields (even without changing their IDs) will change the order of the `value` indices. (This means that a seemingly "no-op" change to reorganize enums may affect code that (incorrectly) relied on the order of `value()`.
PiperOrigin-RevId: 688297400
based one.
This reduces binary size and runtime dispatch costs.
Also, since we are changing the declaration of the type trait, take the opportunity to remove the validator from the template parameters. It can be inferred directly from the type if we add traits for the enum.
PiperOrigin-RevId: 688151072
This CL migrates messages, enums, and primitive types all onto the same blanket
implementation of the `ProxiedInMapValue` trait. This gets us to the point
where messages and enums no longer need to generate any significant amount of
extra code just in case they might be used as a map value.
There are a few big pieces to this:
- I generalized the message-specific FFI endpoints in `rust/cpp_kernel/map.cc`
to be able to additionally handle enums and primitive types as values. This
mostly consisted of replacing `MessageLite*` parameters with a new `MapValue`
tagged union.
- On the Rust side, I added a new blanket implementation of
`ProxiedInMapValue` in rust/cpp.rs. It relies on its value type to implement
a new `CppMapTypeConversions` trait so that it can convert to and from the
`MapValue` tagged union used for FFI.
- In the Rust generated code, I deleted the generated `ProxiedInMapValue`
implementations for messages and enums and replaced them with
implementations of the `CppMapTypeConversions` trait.
PiperOrigin-RevId: 687355817
When you call a map field setter, we currently make an unnecessary extra copy,
so this CL fixes that problem.
I followed the example of how we already handle this for repeated field
setters. This required adding a new move setter thunk for map fields with the
C++ kernel. Originally I tried instead to add an FFI endpoint that could swap
two `RawMap` pointers, but it turned out to be difficult to implement this in a
way that worked correctly when the two maps are not on the same arena.
PiperOrigin-RevId: 687334655
There is really no reason for the Java compiler code to call into the internal
C++ implementation of HasHasbit. In the future, the two implementations may
evolve separately and this decoupling can make it easier.
PiperOrigin-RevId: 686672397
We already use `ABSL_LOG` everywhere instead of `LOG`, so we don't need a
dependency on "third_party/absl/log/log.h". We already use
"third_party/absl/log/absl_log.h" instead.
PiperOrigin-RevId: 685881253
Currently, when a project that includes protobuf is compiled using -Werror, the build will fail due to these variables not being initialized. This fixes this warning allowing the build to complete successfully
Closes#17052
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17052 from guitar24t:main a0d295c222
PiperOrigin-RevId: 685735896
Protobuf Team Bot
Protobuf Team Bot
Tony Liao
Ilya Tokar
Sandy Zhang
Mike Kruskal
Chris Kennelly
Joshua Haberman
Evan Brown
Adam Cozzette
Zoey Greer
Mark Hansen
Robert