Motivation: we are planning to store split repeated fields in the split struct as pointers to repeated fields, which requires not accessing "$field$" directly.
We avoid using "_internal_$name$()" and "_internal_mutable_$name$()" in the implicit weak field case so that we can avoid linking in the message (as tested in implicit_weak_fields_test).
PiperOrigin-RevId: 525862155
This CL does not change the formatting of any of the string templates;
it "only" reorganizes the file and updates the names of everything to match
other migrated files. Followup CLs will update the string templates.
PiperOrigin-RevId: 525833833
This should fix#12374, #12375, and #12450. The `protobuf_PROTOC_EXEC` variable
is not defined, and I think `protobuf::protoc` is what we should be using
instead.
PiperOrigin-RevId: 525591320
This is inspired by https://github.com/protocolbuffers/protobuf/issues/12306,
but does not show those failures, so clearly it doesn't catch everything, but
figured some coverage is better than none.
PiperOrigin-RevId: 525134469
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
The intent of this change is to take the best ideas from the C++ backend, such as having generator objects that can cache pre-computed state, while minimizing duplication.
Where possible, we take the approach of making the C++ and UPB kernel-specific code as similar as possible, since this reduces the number of templates we need to keep in sync.
PiperOrigin-RevId: 524903073
FieldOptions.ctype is public and CORD support is implemented for [ctype=CORD] on "bytes" fields. Include a public comment for CORD about use and supported types.
PiperOrigin-RevId: 524383969
This CL introduces two new files, names.h and context.h.
The former is intended to hold functions that generate the stringified names of things to splat into text templates. The latter holds per-invocation options, and a Context struct that makes it easy to thread extra information throughout the codegen backend.
PiperOrigin-RevId: 524366974
PEP634 introduces structural pattern matching. This works out of the box for most parts of protobuf messages, but fails for sequence matching (defined in https://peps.python.org/pep-0634/#sequence-patterns). This is caused by the underlying containers missing the newly introduced Py_TPFLAGS_SEQUENCE flag (see 069e81ab3d).
This simply adds the flag, making the following fall into the first case:
```
message = test_pb2.TestMessage(int_sequence=(1, 2, 3))
match message:
case test_pb2.TestMessage(int_sequence=(1, *rest)):
print(f"message.int_sequence is a seq starting with 1, ending in {rest}")
case _:
print(f"No case on 'int_sequence' matched! Value: {message.int_sequence}")
```
PiperOrigin-RevId: 524326722
Before this CL all messages were generated in the top-level crate module. With
this change we generate messages under the module specified by the package
declaration in the .proto file.
Dots are interpreted as submodule separator in consistency with how C++
namespaces are handled.
Note that name of the proto_library target still remains to be used as the crate name. This CL only adds crate submodules dependeing on the specified package.
PiperOrigin-RevId: 524235162