The fact that our `:protobuf_nowkt` target actually does depend on the
well-known types is causing a dependency cycle for Kythe. This fixes that so
that `:protobuf_nowkt` no longer depends on the well-known types.
PiperOrigin-RevId: 684160567
GPBUnknownFieldSet and the related apis have been replaced by
GPBUnknownFields. The new api allows the Objective-C Protobuf
implementation to be fully conformant around requirements for
parsing/re-serialization of unknown fields.
PiperOrigin-RevId: 684140581
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 684136800
Reserved field options used for `protoc-gen-env` and `protoc-gen-default`, implemented here: https://github.com/MarnixBouhuis/confpb
I've recently released a protoc plugin for generating defaults / binding environment variables to go protobuf structs. For this I would like to reserve the field options used.
Closes#18507
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18507 from MarnixBouhuis:patch-1 63e3440062
PiperOrigin-RevId: 684103559
If the first check passed (we're an ArrayList) then we aren't a ProtobufArrayList, and there's no point checking.
Micro-optimisation.
PiperOrigin-RevId: 683793700
I think all these generics only change things at compile-time, not at runtime. So should be safe.
It's not a huge win; there's still some unchecked casts. But I was able to remove some unchecked casts, and some warning suppressions, so it's incrementally better.
PiperOrigin-RevId: 683793374
objects in the slow path. It reduces binary size.
Some calls already took care of doing so, but it is easy to miss.
Remove the now unused NewFromPrototype and Merge functions from the traits.
PiperOrigin-RevId: 683634339
See godbolt for Android ART compiler: https://godbolt.org/z/M9dWhdqbf
This optimisation brings the implementation down from 284 bytes to 272 bytes.
- `GeneratedMessage$Builder SingleFieldBuilder.getBuilder() [284 bytes]`
- `GeneratedMessage$Builder SingleFieldBuilder.getBuilder__withLocalVariable() [272 bytes]`
It's not big. It's just a few instructions dropped. These were dropped just before the `ret`:
```
-mov x23, x1
-ldr w0, [x23, #8]
```
And this load dropped before calling `markClean`.
```
-ldr w1, [x23, #8]
```
PiperOrigin-RevId: 683619150
https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.3
The JLS guarantees this is the same:
> A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.
PiperOrigin-RevId: 683416604
https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.3
The JLS guarantees this is the same:
> A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.
In practice, Android's optimising compiler saw that this was unnecessary, and skipped generating 'and' instructions. So this isn't a performance boost, just a cleanup.
PiperOrigin-RevId: 683395327
https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.3
The JLS guarantees this is the same:
> A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.
In practice, Android's optimising compiler saw that this was unnecessary, and skipped generating 'and' instructions. So this isn't a performance boost, just a cleanup.
PiperOrigin-RevId: 683389646
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 683269532
Protobuf Team Bot
Mike Kruskal
Protobuf Team Bot
Adam Cozzette
Thomas Van Lenten
Hong Shin
Marnix Bouhuis
y-yagi
Anuraag (Rag) Agrawal
Mark Hansen
Xufei Tan
Konstantin Pavlov