This prevents shadowing of `java.lang` package commonly used in protobuf gencode. Existing extensions named `java` may or may not previously fail to compile depending on if the contents of their .proto result in gencode using `java.lang`. This is needed to fix `java_features.proto` lite gencode since enum gencode uses `java.lang`. Fields named `java` should already be escaped.
*Warning: This may break user code for existing protos with extensions named `java`. References to the extension should be renamed to use `java_` e.g. registry.add(GeneratedClassName.java_)*
PiperOrigin-RevId: 632508249
The previous change claimed to do this in addition to `true` and `false`, but it was not actually in the code.
To reiterate the text from the earlier change, now actually reflected entirely in the code:
> The identifiers `true`, `false`, and `null` are effectively reserved words in Java, although for some reason they are listed separately from the "keywords" in the Java Language Specification.
>
> This doesn't matter for regular fields, because a proto field called `true` will be accessed with `getTrue` and `setTrue`. But for extensions, the generated Java code will have a public static field whose name is the same as the name of the extension field, with `_` appended if the name is a reserved word. Previously there was no `_` for `true` etc, so the generated code would not compile.
This change should not affect any existing client code in Java. If someone had tried to use an extension called `true` (etc), they would have found that the generated proto code did not compile. Now it is possible to reference such an extension as `true_`.
PiperOrigin-RevId: 632174190
instead of Reflection. This allows using these functions instead of
`dynamic_cast` for all generated types including LITE.
PiperOrigin-RevId: 632135009
The identifiers `true`, `false`, and `null` are effectively reserved words in Java, although for some reason they are listed separately from the "keywords" in the Java Language Specification.
This doesn't matter for regular fields, because a proto field called `true` will be accessed with `getTrue` and `setTrue`. But for extensions, the generated Java code will have a public static field whose name is the same as the name of the extension field, with `_` appended if the name is a reserved word. Previously there was no `_` for `true` etc, so the generated code would not compile.
PiperOrigin-RevId: 631599695
We modify set_<repeated_field> to accept the IntoProxied type as the value and move the value (avoid copying) whenever possible.
For UPB:
- We fuse the arena of Repeated<T> with the parent message arena.
- We use upb_Message_SetBaseField to set the upb_Array contained in the Repeated<T>.
For C++:
- We generate an additional setter thunk that moves the value.
- The move assignment operator of RepeatedField/RepeatedPtrField is specialized. In order to adhere to the layering check we need to add '#include' statements for all .proto imports to the generated thunks.pb.cc.
PiperOrigin-RevId: 631010333
This is equivalent to C++'s `_IsValid` functions. Since proto3 enums are open,
`is_known` seems to be a better name than the misleading `is_valid`.
C++-specific Protocol Buffers documentation already uses "known fields" and
"unknown enum values" expressions.
PiperOrigin-RevId: 630344180
Previously, we would allocate a boxed Integer when accessing repeated enums, because we used ArrayList<Integer>, which must box the int.
Use IntArrayList and the primitive "int getInt()" method instead.
PiperOrigin-RevId: 630229119
Instead of checking the resolved features, we should really be checking the has_presence helper. Repeated fields, oneofs, and extensions can trigger these conditions when they inherit IMPLICIT, even though it's ignored.
Closes#16664
PiperOrigin-RevId: 630206208
Map fields should remain length-prefixed for now, even if DELIMITED is inherited. Field presence will remain unchanged, but unit-tests are added to make sure proto2/proto3 behaviors stay consistent.
Closes#16549
PiperOrigin-RevId: 630191163
This can cause ODR violations in downstream users who link against both the bootstrapped proto and transitive C++ gencode of java_features.proto. Once protoc is split up, we can turn the bootstrapped proto into a real cc_proto_library target and avoid this problem altogether.
PiperOrigin-RevId: 630099889
Instead of _builder.getFoo() and _builder.setFoo(value), the generated code now uses _builder.foo and _builder.foo = value. When compiling against the Java Proto API, this makes no difference, since the Kotlin compiler treats Java methods getFoo/setFoo as defining a Kotlin property foo. But if a compatible proto API is implemented in Kotlin then there is no such equivalence. Such an implementation would have to define either both forms or just the one that the DSL uses. For a Kotlin API it is more natural to use properties.
Similarly, the generated Java methods getFoosList(), getFoosCount(), getFoosMap(), and getEnumValue() are accessed via property names (foosList, foosCount, foosMap, enumValue).
(This is the second application of this change. The first had to be rolled back because it didn't handle conflict-resolution names correctly.)
PiperOrigin-RevId: 629807104
The field is always set while building the descriptor, even for lazy descriptors.
The `type()` function is called extensively in reflection based code and
removing the call_once has significant performance impact.
PiperOrigin-RevId: 629723749
Provide a specialization for ListAdapter that avoids boxing ints into Integers.
Use this for repeated enum accessors.
In practice, the ints for most enums will fit into the JDK's "boxed int cache", avoiding extra allocations. For large enum numbers, they won't fit, and would allocate. Removing the boxing should also slightly speed up code.
PiperOrigin-RevId: 629583247
Instead of `_builder.getFoo()` and `_builder.setFoo(value)`, the generated code now uses `_builder.foo` and `_builder.foo = value`. When compiling against the Java Proto API, this makes no difference, since the Kotlin compiler treats Java methods `getFoo`/`setFoo` as defining a Kotlin property `foo`. But if a compatible proto API is implemented in Kotlin then there is no such equivalence. Such an implementation would have to define either both forms or just the one that the DSL uses. For a Kotlin API it is more natural to use properties.
Similarly, the generated Java methods `getFoosList()`, `getFoosCount()`, `getFoosMap()`, and `getEnumValue()` are accessed via property names (`foosList`, `foosCount`, `foosMap`, `enumValue`).
PiperOrigin-RevId: 629220383
The last callside that used PrimitiveMut was in our enums code. This change makes it so that enums nolonger implement MutProxied and thus no longer need the PrimitiveMut type.
PiperOrigin-RevId: 629017282
The intent is to avoid codegen issues for simple cases where a message of the shape:
message M {
int32 x = 3
string set_x = 8;
}
Which would otherwise break due to the first field having a setter whose name collides with the second field's getter.
By seeing that 'set_x' matches another field with a common accessor prefixed, it will generate all accessors for that field as though it was named `set_x_8`.
This does not avoid all possible collisions, but should mitigate the vast majority of situations of an accidental collision.
PiperOrigin-RevId: 627776907
This change removes the only remaining instance of SettableValue in a generated accessor. The principled fix is to implement IntoProxied for ProtoStr/[u8], but this will have to wait until we have agreed on & implemented the 1.0 string types. So we'll use AsRef in the meantime in order to not break any user code while allowing us to make progress on IntoProxied and Proxied changes.
PiperOrigin-RevId: 627735404
Proxied is not marked as Sized yet, because ProtoStr is still dynamically sized. We will wait for clarity for the string types before marking Proxied Sized.
PiperOrigin-RevId: 627707544
Protobuf Team Bot
Protobuf Team Bot
Sandy Zhang
Hong Shin
Éamonn McManus
Brent Shaffer
Jakob Buchgraber
Adrian Sadłocha
Mark Hansen
Mike Kruskal
Daniel Kenji Toyama