The purpose is to avoid duplicating the mapping of different types that are only relevant to the serializer but not to the exposed api (e.g. FIXED32 vs INT32)
Treat type=GROUP as rust-type=MESSAGE here which is all that is needed for us to support groups in the rust codegen.
The RustFieldType is parallel to the preexisting FieldDescriptor::CppType which _almost_ does what we need, but it treats Bytes and Strings as the same cpptype which Rust codegen doesn't.
PiperOrigin-RevId: 609416940
Hopefully will make future edits a little easier.
clang-format doesn't do anything with `R"objc(` blocks, and we can't use `R"cc(`
blocks as that gets the ObjC code formatted wrong.
PiperOrigin-RevId: 608678538
Prototiller has subtley different rules about attaching these to objects, and relatively harmless transformations can cause codegen diffs where these move around.
PiperOrigin-RevId: 608648976
Prototiller has subtley different rules about attaching these to objects, and relatively harmless transformations can cause codegen diffs where these move around.
PiperOrigin-RevId: 608402666
Previously, when we call SetRecursiveBuildDispatcher(nullptr), this created a unique_ptr to an AnyInvocable object with a function pointer to a nullptr, which triggers a segmentation fault inside BuildFile.
PiperOrigin-RevId: 607435995
The motivation for this is first that under some combinations of flags it breaks builds and second it's trivial (and possibly zero runtime cost) to fix.
It looks like the possibly bad case "should never happen", but converting this to a null pointer in the error case (which should at least make the failure less problematic) is cheap.
Closes#15846
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15846 from bcsgh:bcsgh/uninitialized 321d649b51
PiperOrigin-RevId: 607404168
We recently updated the codebase to comply with the Bazel layering check, which
essentially requires any C++ header inclusion to be matched with a build
dependency on a target providing that header.
As part of that, I removed a handful of dependencies from the `//:protobuf`
target, since these dependencies were not set up in a way that respected the
layering check. However, I realized that this may cause a number of breakages,
especially since we did not provide the correct public targets until very
recently.
This change effectively adds back in the missing dependencies, so that projects
which do not yet adhere to the layering check can continue to depend on them
indirectly. This way, we still adhere to the layering check and make it
possible for projects that depend on us to do so, but in most cases we won't
immediately break anyone.
PiperOrigin-RevId: 607021111
Useful for test non-codegen types that have their own parsing logic.
Also forward the `ptr` through the post_loop_handler to allow it to fail.
PiperOrigin-RevId: 606714285
`_InternalParse` implementation to use it.
For LITE messages, populate the entry in `ClassData` and remove the override for
`_InternalParse`.
PiperOrigin-RevId: 606364791
Until recently, these targets were dependencies of `//:protobuf` and could thus
be accessed through that target. But now that we are adhering to the layering
check, we need to provide proper access in a way that respects that check. This
change uses top-level alias targets following the existing pattern.
PiperOrigin-RevId: 605123979
- The comment stated that the option does not affect lite, but this appears to be false: in my testing the option affects both lite and full protos.
- The comment failed to mention that the option has no effect when set explicitly to false. It can only be used to opt proto2 into extra checking, it cannot opt proto3 out of the checks.
PiperOrigin-RevId: 605097398
Protobuf Team Bot
Protobuf Team Bot
Chris Kennelly
Thomas Van Lenten
Mike Kruskal
Jakob Buchgraber
bcsgh
Adam Cozzette
aiuto
Marcel Hlopko
Joshua Haberman