Add convenience _opt for singular message fields.
Users can detect if the message is set or unset, and unwrap via into_inner.
PiperOrigin-RevId: 602749065
This is the final CL (part 4 of 4) in the ProxiedWithPresence chain.
In the past, we had returned Mut directly for the `_mut` accessors.
This was a temporary engagement in order to get the other submsg machinery checked in.
As we prep for the finalization of v0.6, we can finally conform to the rest of the `_mut` getters.
$field$_mut now correctly returns $pb$::FieldEntry<'_, $msg_type$> as a part of this.
All test callsites have been updated to `.or_default` in order to test the mutational pathway as before.
PiperOrigin-RevId: 602739186
It seems possible that old data is stored with serialized descriptors. If we
reject old descriptors due to invalid ctype, the change effectively becomes
breaking changes. We should apply this stricter check for edition 2023 or beyond.
PiperOrigin-RevId: 602516135
Instead of silently ignoring `[ctype = XXX]` for non string or bytes fields,
this CL starts failing to build descriptors to call out the issue. This may
cause failures to existing proto schemas but fixing them should be straightforward.
PiperOrigin-RevId: 602441330
right kind of extension. This way you get a compile time failure instead of a
runtime one.
Other extension accessors already have this kind of SFINAE restrictions.
PiperOrigin-RevId: 602418580
RepeatedPtrField had been updated to handle Add/MergeFrom when holding an abstract type MessageLite, hence ExtentionSet no longer needs to have custom workarounds.
PiperOrigin-RevId: 602381489
This is done by specifying suffix punctuation to chomp with WithVars.
If we delete the space on line 64 without also doing the rest of this change, the result is that the comma is not emitted at all.
PiperOrigin-RevId: 601516987
Before this change if a field type was defined in a imported .proto file then our codegen would not generate the field. After this change such fields are correctly generated (see tests). This change is rather trivial as all the supporting infra has been implemented as part of the .proto -> crate mapping CLs.
PiperOrigin-RevId: 601443383
Part 3 of 4 (added a stage).
The getter and mut_getter bifurcate based on the kernel.
upb returns Option<RawMessage>, while cpp returns the RawMessage.
This means that we can't have a unified MessageVTable in vtable.rs, so we've split these out in {upb.rs and cpp.rs}.
$field$_entry is now prepped and populated for the $field$_mut swappage in the following CL.
PiperOrigin-RevId: 601230880
Follow up on #10404, the initial description:
> For the sake of performance, the hex2bin call was removed from the generated PHP code in https://github.com/protocolbuffers/protobuf/pull/8006
However, after this PR all autogenerated files contain binary data, which makes it hard or even impossible to see using common tools (git and github included (i.e. [this file](https://github.com/protocolbuffers/protobuf/blob/main/php/src/GPBMetadata/Google/Protobuf/Struct.php)), as well as some code editors) since most software considers such files as binary ones and not as code.
Alexander suggested using a hex representation of string literals and I updated the original patch a bit, not hex-encoding printable characters.
Benchmarks from [#10404#issuecomment-1635939062](https://github.com/protocolbuffers/protobuf/pull/10404#issuecomment-1635939062)
```
The percent of printable chars: 0.83869 (80112 vs 15408)
hex parsing: 3.22371, length=382090
hex2Bin parsing: 1.18489, length=191059
hexAscii parsing: 0.89524, length=142306 (suggested option)
binary parsing: 0.26437, length=95542
```
Closes#13911
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13911 from mikhainin:do_not_store_binary_data_inside_php_files 490958e165
PiperOrigin-RevId: 601123255
Stage 2 of 3.
Fleshed out the bodies required by the aforementioned contracts above.
We create MessageVTable and utilize the `unsafe fns` directly in `message.cc` -- a departure from PrimitiveVTables.
In the final followup CL, we will perform the field_entry swapover and update all unit tests.
PiperOrigin-RevId: 600567890
A fuzz test discovered that our JSON parser will accept "overlong" UTF-8
characters, i.e. encodings that use more bytes than necessary. We should reject
these overlong encodings, because they are not considered valid.
To fix this problem, I updated the JSON lexer to rely on utf8_range for
checking UTF-8 validity. This way, the lexer does not need to do any UTF-8
validation of its own, but just has to interpret the UTF-8 enough to know how
many bytes to read for each character.
PiperOrigin-RevId: 599657903
Protobuf Team Bot
Mike Kruskal
Hong Shin
Protobuf Team Bot
Jakob Buchgraber
Alyssa Haroldsen
Dennis Shao
dmaclach
Sandy Zhang
Mikhail Galanin
Isuru Fernando
Harald Kjær Nielsen
Marcel Hlopko
Adam Cozzette