The proto
message A {
SomeMessage text_field = 1;
SomeMessage text = 2;
}
will fail java compilation with a name clash: `method getTextFieldBuilder() is already defined in class...` This is because the `text` field creates a private method (`get{Text}{FieldBuilder}`) which conflicts with the public getter (`get{TextField}{Builder}`) for field 1.
Unlike some name clashes, this one is with a private method and we can just rename the method in this file. Other name clash issues:
- https://github.com/protocolbuffers/protobuf/issues/15411
- https://github.com/protocolbuffers/protobuf/issues/17367
There's some precedent for the `internal` prefix with the protected `internalGetFieldAccessorTable` method on GeneratedMessage.
PiperOrigin-RevId: 694108040
Considering that protobuf depends on absl already, we don't need protobuf's
version of PREDICT_TRUE|FALSE. This CL shrinks port_def.inc.
PiperOrigin-RevId: 694015588
Instead of fetching dependencies by default, we will first look for a local installation and only fetch as a fallback. Two new options are added for forcing either of these behaviors. protobuf_FORCE_FETCH_DEPENDENCIES will always fetch dependencies, and protobuf_PREVENT_FETCH_DEPENDENCIES will never do so.
#test-continuous
PiperOrigin-RevId: 693898394
Packed repeated fields without cached_size use static_cast<int32_t> that may be confused
with bad field names. This change fixes it by using ::int32_t.
PiperOrigin-RevId: 693884622
With C++17 being baseline, PROTOBUF_NODISCARD is no longer necessary. Directly
using [[nodiscard]] makes port_def.inc smaller.
PiperOrigin-RevId: 693808783
Technically these methods fail either if the field is primitive (non-message) or if the field is repeated. However it is confusing to have a repeated message field claim to be of type 'message' and then fail with an error message that claims you need a message type.
PiperOrigin-RevId: 693789370
Protobuf Team Bot
Hong Shin
Protobuf Team Bot
Mike Kruskal
Chris Kennelly