EDITION_UNSTABLE. Note that this CL is effectively no-op.
* int32, int64, uint32, uint64
It also removes the following now-redundant types.
* fixed32, fixed64, sfixed32, sfixed64, sint32, sint64.
The goal is to stop introducing new numeric types that use varint coding for
efficiency at the expense of larger wire data.
PiperOrigin-RevId: 854252074
We plan to change protoc_minimal on how to interpret common numeric types like
int32, uint32, int64, uint64. Such change interacts badly with existing
conformance tests without much test coverage benefits.
This CL changes conformance tests to use bytes fields rather.
PiperOrigin-RevId: 854236148
As of today:
- GoProto and C# serialize google.protobuf.Empty-packed-into-Any with the `"value":{}` field set
- Only Go, C# and Swift accept that shape at parse time
In an attempt to make spec match reality, the public ProtoJSON documentation has now been clarified to match the common behavior that nearly all implementations have in practice.
Note that this conformance test added is only mandating that implementations:
1) Accept it without the `"value":{}` set
2) Serialize it without it set (by virtue of the round trip coming back to C++Proto in the test harness which does not accept it).
A test that confirms an implementation affirmatively rejects if the "value":{} is set is not added here; especially in the near term it is sensible for implementations like Go and C# to locally continue to accept that shape for backwards compatibility reasons within the same language, as long as it emits without it by default so that other languages can parse what it emits. For that reason, a test affirming a parse failure when it is present is not added to the conformance test suite failure today.
https://github.com/protocolbuffers/protobuf/issues/24445
PiperOrigin-RevId: 854155587
We unfortuantely have no holistic startegy to avoid broken gencode from cross-type name collisions. We hold a high bar for special case mangling cross-type collisions, but this specific naming pattern combination is recommended by AIP 157.
Note that we will still break if the Xyz message and the XyzView enum are defined in separate .proto files but built in the same crate. It is very difficult for us to avoid that specific collision, so we are punting on it for now and only handling the case where the message and enum are defined in the same file. Especially when using blazel, we recommend one proto_library() per proto file, which would avoid that topic from being a concern.
PiperOrigin-RevId: 853935768
- `class_based`: Legacy behavior
- `migration`: Legacy behavior remains, and C functions added
- `c_function`: All extensions and registries are generated as C functions only
This mitigates risks of collisions of generated *Root classe names, and reduces
binary overhead of proto extensions.
PiperOrigin-RevId: 853860971
#test-continuous
This was a legacy shim for C++11 and C++14 support, that's no longer needed. It also seems to be causing potential issues for unsupported compilers, when we disable it.
PiperOrigin-RevId: 853822318
This allows the compiler to potentially optimize away unused message types more effectively, as demonstrated by the size reductions observed when unused messages are added in a test proto file.
PiperOrigin-RevId: 853529287
With the path length limitations from Bazel fixed, we ended up reversing course on this plan. We will continue to support MSVC and this flag hasn't done anything for a few releases.
PiperOrigin-RevId: 853482413
cc_toolchain now respects the prefer_prebuilt_protoc flag. When the flag is set to true, the toolchain uses the full protoc binary instead of protoc_minimal, enabling prebuilt protoc support.
Follow up to this is to have minimal protoc released as an artifact and use that.
Closes#25168
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/25168 from thesayyn:cc_toolchain_prebuilt 30451beb53
PiperOrigin-RevId: 853463775
This documents that they may throw if UNSPECIFIED was provided.
Note that this conditional applies to legacy closed enums as well, not just open-enum-fields, since in legacy closed enums the underlying enum is open and will have an UNSPECIFIED value available that will still throw, though it will be somewhat more rare of a concern because `x.setX(y.getX())` can never throw if x and y are the same message type, it will still be a reachable exception if its a legacy closed field on `x` but an open field on `y`.
Fixes https://github.com/protocolbuffers/protobuf/issues/22829
PiperOrigin-RevId: 853401993
Check if each byte in the array is a valid representation for a bool,
i.e. 0 or 1. If so, skip varint parsing, and help the compiler with making
conversion to bool trivial.
PiperOrigin-RevId: 853089336
We got a bug report for Go Protobuf where users discovered that in Go Protobuf,
parsing does not fail despite trailing garbage after numbers:
related to https://github.com/golang/protobuf/issues/1678
Let’s add these cases to the conformace test suite to ensure consistent behavior
across the various Protobuf implementations.
PiperOrigin-RevId: 853056737
The pyi generator now includes Kythe annotations for:
* Extension field constants (e.g., `EXTENSION_FIELD`).
* Field number constants (e.g., `STRING_FIELD_FIELD_NUMBER`).
* `Create` methods in generated Stubby client classes.
These annotations allow the Python indexer to link these generated symbols back to their definitions in the `.proto` files.
PiperOrigin-RevId: 852971617
This harmonizes the BinaryToJson behavior with wire_format.cc skip unknown: it still has the odd implication of truncating the length varint, but it will now correctly parse-fail if the length is larger than the remaining bytes (before it just skipped to the end of the buffer) and also parse-fail if the 32nd bit is set (which is viewed as a negative length by CodedInputStream and would have just continued parsing without skipping anything)
Fixes https://github.com/protocolbuffers/protobuf/issues/25092
PiperOrigin-RevId: 852791222
* If counting varints revealed that each varint takes one byte, skip varint
parsing. Idea by sbenza@.
* Do not check if all varints necessarily fit under the current capacity,
which was done to skip counting varints. Counting varints is now useful
also to check if each varint takes one byte, and it is now cheap enough
to perform unconditionally.
There were actually two capacity checks by mistake, and in the case of
enough capacity we were doing a slower loop with Add instead of a faster
loop with setting an element.
PiperOrigin-RevId: 852517269
This is only adding the annotation on cases that match standard idioms that return values can be ignored: like collections add/addAll/remove and Builders returning `this`
PiperOrigin-RevId: 852435246
This covers two types of failures:
* Methods that are logically const and failure to consume the result indicates a bug
(an unnecessary call, etc.)
* Methods that return significant errors (failure to parse, etc.) that should not be
unintentionally ignored.
PiperOrigin-RevId: 852406706
This covers two types of failures:
* Methods that are logically const and failure to consume the result indicates a bug
(an unnecessary call, etc.)
* Methods that return significant errors (failure to parse, etc.) that should not be
unintentionally ignored.
PiperOrigin-RevId: 852313694
