These utilities provide a way to embed a FeatureSetDefaults message into generators or runtimes that need to implement feature resolution. They use protoc to handle the tricky reflection-based algorithm over feature protos, leaving only simple merges to be implemented in other languages. See docs/design/editions/editions-life-of-a-featureset.md for more information.
PiperOrigin-RevId: 574554333
This doesn't change the tests at all, but refactors them to be more reusable in different contexts. Specifically, this will make it easier to add corresponding editions-based tests. This also splits the concept of "uses a proto3 message" and "runs proto3 tests", in preparation for that change.
PiperOrigin-RevId: 574310612
This doesn't change the tests at all, but refactors them to be more reusable in different contexts. Specifically, this will make it easier to add corresponding editions-based tests. This also splits the concept of "uses a proto3 message" and "runs proto3 tests", in preparation for that change.
PiperOrigin-RevId: 574299923
The switch from aggregate initialization to explicit constructors in `Impl_` has been enabled since 09/06, and no issues have been reported or found. This change removes the back-out option and code from the various sources for aggregate initialization.
PiperOrigin-RevId: 574161896
addresses https://github.com/protocolbuffers/protobuf/issues/12714 by dumping more concise debug info for protobuf messages and repeated fields via the `serializeToJsonString` function. Additionally, message types which serialize into something other than an array (e.g. `Google\Protobuf\Value`, `Google\Protobuf\Timestamp`, etc) are handled in a special way to make their output consistent with other messages.
```php
$m = new Google\Protobuf\DoubleValue();
$m->setValue(1.5);
var_dump($m);
```
will output
```
object(Google\Protobuf\DoubleValue)#12 (1) {
["value"]=>
float(1.5)
}
```
Closes#12718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12718 from bshaffer:php-add-debuginfo c40a6f91de
PiperOrigin-RevId: 574115431
`Options` is a fairly heavy class and not easy to initialize, and not required for the common functions we change here allowing a lower bar for re-use.
PiperOrigin-RevId: 573920014
We continue our foray into googletest-rust [1], this time with homegrown matchers.
Our unit tests will now be able to check is_unset() and is_set() for all types that implement ProxiedWithPresence. In practice, this boils down to [u8] and ProtoStr.
Note that we've broken out matchers_upb and matchers_cpp, similar to what was done with aliasing here [2].
[1] https://github.com/google/googletest-rust
[2] 9a0bc392b3 (diff-08e5182ff36ad340a3bfb628995524a2a36a89b59a514ba027b0f25e048dd5c3R90)
PiperOrigin-RevId: 573895179
We're adding googletest-rust as a dependency for our rust tests, so let's ensure that our opensource build has access to the same crates.
PiperOrigin-RevId: 573863399
We had previously commented out the upb portion of simple_nested_test.
This is because nonmutable getters have submessages being NULL by default.
This means that trying to fetch anything, like a simple scalar from that nested message would segfault.
This CL makes the externC return an Option<RawMessage> since we've discovered that upb can return NULL. This way, we can check for `None` and handle the NULL case appropriately.
We know that the NULL pathway can only come from terra upb, since
cpp automagically constructs submsgs if they don't exist.
We've augmented upb.rs to contain a scratch space that allocates a zeroed-out contiguous chunk of memory @64KB. Since a block of zeroed-out memory is a legit message from upb's point of view, we can provide $pbr$::ScratchSpace::zeroed_block() to upb in order to get the default submessage behavior we want from upb.
This block is lazily allocated upon first request. This means that a consumer of the cpp kernel will not incur an additional cost.
PiperOrigin-RevId: 573840755
This is likely the cause of our macos cmake flakes. Both the lite and full tests trigger codegen of the lite protos, but there's no dependency between them. This creates a race condition, where it's possible for the files to be invalid by the time one of their builds is triggered. This is consistent with the error message we see:
liblibtest_common_lite.a(unittest_lite.pb.cc.o) has no symbols
PiperOrigin-RevId: 573381442