This will be used to make the method and enum to package-private and later to visibility-restrict other deprecated APIs for editions to prevent backslide.
PiperOrigin-RevId: 518028723
At the moment, `protoc` ignores `option deprecated = true` for these entities.
It seems good to add the tag `@deprecated` to highlight the deprecation in the client code. It works for fields bot not for messages/service/method.
I wanted to add the test for this change, but I couldn't find any test for the generator. I will be happy if you can guide me in the right direction
Closes#12265
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12265 from negram:add-message-deprecate fa52e15366
PiperOrigin-RevId: 518007790
Downstream bazel projects that depend on protoc would need to provide googletest dependencies when it should not be necessary to do so.
Fixes#11409Closes#12267
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12267 from prestonvanloon:remove-erroneous-googletest-dep 09fd163094
PiperOrigin-RevId: 517974450
These will become meaningless once we migrate to editions. In the meantime, we've implemented APIs to expose the differences between proto2 and proto3 in terms of the features we plan to release in edition 2023.
PiperOrigin-RevId: 517433756
For legal reasons we unfortunately cannot accept any external contributions to
the well-known type protos, so this change reverts the small number of changes
we have received so far.
PiperOrigin-RevId: 517211904
No need for a loop that that calls tryConsumeString or tryConsumeByteString repeatedly, since ConsumeByteString already loops itself.
PiperOrigin-RevId: 517202228
In this CL we're adding the barebones infrastructure to generate Rust proto messages using UPB as a backend. The API is what we call a V0, not yet production-quality, not yet rigorously designed, just something to enable parallel work.
The interesting part of switching backend between UPB and C++ will come in a followup.
PiperOrigin-RevId: 517089760
This fixes the following issue:
- In `FieldSet#getMessageSetSerializedSize` we delegate to `LazyField` for getting its size.
- Before this change, in `FieldSet#writeMessageTo` we do not delegate to LazyField's `byteString` method. Instead, we call `getValue` on the `FieldSet`.
- It's not guaranteed that `fieldSet.getSerializedSize() == fieldSet.getValue().getSerializedSize()`.
In particular, this can lead us to run into the message "Serializing com.google.protobuf.DynamicMessage to a byte array threw an IOException (should never happen)" because of mispredicted output size.
We fix the issue by following similar logic to `MessageSetSchema`- if "getSerializedSize" delegates to the LazyField, then the serializer should as well.
PiperOrigin-RevId: 516658372
For now, we'll just be hiding syntax getters on FileDescriptor. Later on this will likely grow to include other APIs that distinguish between proto2/proto3.
PiperOrigin-RevId: 516334230
Sandy Zhang
Protobuf Team Bot
Martijn Vels
Mikhail Galanin
Preston Van Loon
Jakob Buchgraber
Mike Kruskal
Protobuf Team Bot
Marcel Hlopko
John Cater
Deanna Garcia
Adam Cozzette
zhangskz