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
`google.protobuf.Any` formatting with indentation was somewhat off.
Formatting an `Any` as root object:
```json
{"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
changes to
```json
{
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
For messages were `Any` is in a nested field the change makes more of a visual impact.
The `c` field seems to be at the same level as the `anyField`, but it's nested so it should be indented:
```json
{
"anyField": {"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
changes to:
```json
{
"anyField": {
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
Closes#16785
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16785 from q42jaap:main 72deed6ed7
PiperOrigin-RevId: 632506226
- add google.protobuf.proto module
- wrap generated SerializeToString and ParseFromString to the new module:
def serialize(message: Message, deterministic: bool=None) -> bytes:
"""Return the serialized proto."""
def parse(message_class: typing.Type[Message], payload: bytes) -> Message:
"""Given a serialized proto, deserialize it into a Message."""
PiperOrigin-RevId: 632223409
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
This was added to protobuf_deps.bzl in cl/629786458 and no longer needs to be specified directly in WORKSPACE. However, an alias is needed to prevent users from breaking when upgrading from 26.x -> 27.x due to the obsolete load pointing to the wrong path.
This alias will be removed in a future release, tentatively 4.30.x.
PiperOrigin-RevId: 631821637
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
upb users currently need to manually fetch a oneof field in order to clear it.
In this CL, we add a convenience method to do that in one fell swoop.
PiperOrigin-RevId: 631454136
The idea here is to set the existing config "config_msvc" not only
when "msvc-cl" is specified but also when "clang-cl" is specified.
Keep in mind that clang-cl support in protobuf remains to be only
best-effort and untested for now.
PiperOrigin-RevId: 631195504
(Second attempt. The first attempt missed ListValue)
The “in” operator will be consistent with HasField but a little different with Proto Plus.
The detail behavior of “in” operator in Nextgen
* For WKT Struct (to be consist with old Struct behavior):
-Raise TypeError if not pass a string
-Check if the key is in the struct.fields
* For WKT ListValue (to be consist with old behavior):
-Check if the key is in the list_value.values
* For other messages:
-Raise ValueError if not pass a string
-Raise ValueError if the string is not a field
-For Oneof: Check any field under the oneof is set
-For has-presence field: check if set
-For non-has-presence field (include repeated fields): raise ValueError
PiperOrigin-RevId: 631143378
Sandy Zhang
Jaap Taal
Mark Hansen
Protobuf Team Bot
Hong Shin
Protobuf Team Bot
Éamonn McManus
Joshua Haberman
Eric Salo
Jie Luo
Brent Shaffer
Yohei Yukawa