I noticed that the use of `unsafe` here was not really necessary, so I tweaked
the code to remove it. If we avoid using `__unstable_leak_raw_message()` then
we don't need to unsafely create a `NonNull`.
PiperOrigin-RevId: 693357956
Protobuf 6.30.0 will change the return types of Descriptor::name() and other methods to absl::string_view. This makes the code work both before and after such a change.
PiperOrigin-RevId: 693050410
Allocate extension number 536000000 to Buf
Extension numbers will be allocated one at a time by request.
Once extension declarations are open-sourced for extensions in descriptor.proto, we will move these declarations into a separate config file to declutter descriptor.proto.
PiperOrigin-RevId: 692315472
These were already being grouped because we group by branch name for scheduled workflow runs. By not canceling in-progress runs, a single stalled execution could block our CI indefinitely.
PiperOrigin-RevId: 692298661
This change adds `Sized` as a supertrait of our `SealedInternal` trait, to
ensure that our codegen traits cannot be used as trait objects (i.e. with
`dyn`). I was thinking it would be prudent to do this early so that we don't
end up accidentally forced to support `dyn` usage.
Some of the traits already disallowed `dyn` as a result of having `Sized` as an
indirect supertrait or for other reasons, but a few traits did allow trait
objects.
If we ever do want to support some kind of type-erased message, I suspect we
will want to provide our own implementation. At least for C++, we already have
a vtable in the kernel, so it would seem wasteful to have Rust duplicate it.
PiperOrigin-RevId: 692195274
This makes it possible to match views by value:
```rust
expect_that!(
response.clients(),
unordered_elements_are![
proto_eq(proto!(Client { name: "Alice" }).as_view()),
proto_eq(proto!(Client { name: "Bob" }).as_view())
]
);
```
where `clients()` return an iterator over `ClientView` values.
PiperOrigin-RevId: 692192744
As an optimization, string fields are initialized with a pointer to a global
immutable std::string instance and create a local std::string only when
"set". If a field has hasbits, it presents a possibility that the hasbit is set
but the string field is still pointing to the global empty string instance.
This can happen, for example, when the field is implicit-presence but hasbit
has been generated for it.
Maintaining an invariant that hasbit is set iff string is nondefault can
simplify the implementation of destructors and message.Clear(). The code would
not need to branch further after scanning hasbits, instead it can always assume
that a local std::string object exists as soon as it sees that the hasbit is
set.
However, this does require an else block in the merge implementation of
implicit-presence string fields. When hasbits are implemented for
implicit-presence string fields, merging from a non-present (i.e. empty) string
field requires a nondefault std::string instance to be created. On the other
hand, branches in Clear() can be eliminated. We think this is the right
tradeoff because:
1. The allocation of nondefault string instance can only happen when the source
proto has hasbit set but the field is empty. This is a relatively rare
scenario.
2. Clear() is called every time a protobuf object is "overwritten" via an
assignment operator or ParseFrom(). This happens probably more frequently than 1.
PiperOrigin-RevId: 691951661
N.B.:
- This change is not intended to affect any well-defined protobuf behaviour in
an observable way.
- The wire parsing codepath is not affected.
- This change only affects the C++ protobuf implementation (other languages are
not affected).
- sizeof proto3 message objects may increase in 32-bit increments to
accommodate hasbits.
- When profiled on some of Google's largest binaries, we have seen a code size
increase of ~0.1%, which we consider to be a reasonable increase.
There are quite a few terminologies in the title:
- **singular**: a field that is not repeated, not oneof, not extension, not lazy,
just a field with a simple primitive type (number or boolean), or
string/bytes.
- **proto3**: describes behaviour consistent to the "proto3" syntax.
This is equivalent to `edition = "2023"` with
`option features.field_presence = IMPLICIT;`.
- **implicit presence**: describes behaviour consistent with "non-optional"
fields in proto3. This is described in more detail in
https://protobuf.dev/programming-guides/field_presence/#presence-in-proto3-apis
This change enables C++ proto3 objects to generate hasbits for regular proto3
(i.e. non-`optional`) fields. This code change might make certain codepaths
negligibly more efficient, but large improvement or regression is unlikely. A
larger performance improvement is expected from generating hasbits for repeated
fields -- this change will pave the way for future work there.
Hasbits in C++ will have slightly different semantics for implicit presence
fields. In the past, all hasbits are true field presence indicators. If the
hasbit is set, the field is guaranteed to be present; if the hasbit is unset,
the field is guaranteed to be missing.
This change introduces a new hasbit mode that I will call "hint hasbits",
denoted by a newly-introduced enum, `internal::cpp::HasbitMode::kHintHasbit`.
For implicit presence fields, it may be possible to mutate the field and have
it end up as a zero field, especially with `mutable_foo` APIs. To handle those
cases correctly, we unconditionally set the hasbit when `mutable_foo` is
called, then we must do an additional check for field emptiness before
serializing the field onto the wire.
PiperOrigin-RevId: 691945237
cpp extension added the API in https://github.com/protocolbuffers/protobuf/pull/7498
Pure python and upb do not support it and filtered out the test
This API does not exists in any other language except C++.
PiperOrigin-RevId: 691870623
.index() is dependent on the order specified in the .proto file.
Minitables create their own ordering, which represent the true index that we're interested in set_alias.
This can be fetched via .layout_index when we have a upb::FieldDefPtr.
PiperOrigin-RevId: 691825782