This should never happen, so I don't think it matters much exactly what kind of
exception we throw. We could even arguably return null, but this option saves a
lot of space while still preserving some error checking.
See https://godbolt.org/z/jKhcKs3x1 for code gen.
This generates much tighter bytecode and ARM assembly than alternatives.
As this code is generated many times over, small wins in code size here can
reduce icache pressure, APK size, and OAT size.
This java code:
```java
Object uoe() {
throw new UnsupportedOperationException();
}
Object npe2() {
throw null;
}
```
Generates this dex code:
```
.method uoe()Ljava/lang/Object;
new-instance v0, Ljava/lang/UnsupportedOperationException;
invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V
throw v0
.end method
.method npe2()Ljava/lang/Object;
const/4 v0, 0x0
throw v0
.end method
```
Which generates this OAT code:
```
java.lang.Object SomeProto.uoe() [84 bytes]
0x000081c0 sub x16, sp, #0x2000 (8192)
0x000081c4 ldr wzr, [x16]
StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
0x000081c8 str x0, [sp, #-48]!
0x000081cc str x22, [sp, #24
When swap is being called on a scalar field in an implicit-presence message,
calling accessors on the swapped-out field should give zero.
When swap is being called on a repeated field in an implicit-presence message,
calling accessors on the swapped-out field should give the empty list.
When swap is being called on a oneof field in an implicit-presence message,
calling `has_foo` on the swapped-out field should return false.
PiperOrigin-RevId: 684582416
These have been empty and forwarding to the real versions for
years now. Everyone should have migrated to the GPB[Name].pbobjc.h
versions instead.
PiperOrigin-RevId: 684580342
As an optimization, we maintain a default instance of a string in memory, and
messages with uninitialized fields will be constructed with a pointer to this
default string object. The destructor should clear the field only when it is
"set" to a nondefault object.
If `ClearNonDefaultToEmpty()` is ever called on a default string...
- It will result in undefined behaviour. Most likely, it results in overwriting
an object in memory (which is already full of zeros) with another bunch of
zeros.
- It's quite bad for a number of reasons:
1. It can confuse TSAN.
2. It blocks us from moving the default instance of the string into the
`.data` section. Having the default instance of the string live in
read-only memory would be beneficial for memory safety. It would play well
with hugepages. It would also eliminate some runtime cost of instantiating
the default instance of the string.
This change adds a debug-fail so that users don't call this function "unsafely".
PiperOrigin-RevId: 684569674
`ProtoStr` is a public type and it has a public
method `to_str`, however `to_str` returns a private
type `Utf8Error`, which triggers `private-interfaces` [1].
Exporting string::Utf8Error makes it possible for other
crates to wrap it in another error type and propagate
it with "?".
[1] https://doc.rust-lang.org/beta/rustc/lints/listing/warn-by-default.html#private-interfaces
PiperOrigin-RevId: 684477510
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
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
An error occurred
]
```
And this load dropped before calling `markClean`.
```
-ldr w1, [x23, #8
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
Mark Hansen
Protobuf Team Bot
Tony Liao
Thomas Van Lenten
Adam Cozzette
Hong Shin
Noah Watkins
Mike Kruskal
Protobuf Team Bot
Marnix Bouhuis
y-yagi
Anuraag (Rag) Agrawal
Xufei Tan