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
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 only public target here is the edition defaults helper macro, which can be used by external runtimes and plugins. None of this code is C++-specific though, and should be organized higher up. Appropriate aliases are also placed at the top level for public targets
PiperOrigin-RevId: 625392504
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
GeneratedMessage, not GeneratedMessageV3.
Please rerun protoc on your .proto files to regenerate the binding code.
https://protobuf.dev/news/2023-12-05/https://protobuf.dev/support/cross-version-runtime-guarantee/
To fix source compatibility with surrounding code make these replacements:
GeneratedMessageV3 --> GeneratedMessage
SingleFieldBuilderV3 --> SingleFieldBuilder
RepeatedFieldBuilderV3 --> RepeatedFieldBuilder
PiperOrigin-RevId: 597642289
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
Éamonn McManus
Mike Kruskal
Mike Kruskal
Protobuf Team Bot
Sandy Zhang
aiuto
Dennis Shao
Joshua Haberman
Jie Luo
Protobuf Team Bot
Adam Cozzette
ericsalo
deannagarcia
zhangskz
Deanna Garcia