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
When we get a pull request from outside the protobuf repository, the tests will
not run until a protobuf team member adds the `safe for tests` tag. This change
updates the error message to make it more clear what has to happen to get the
tests to run.
Fixes#15847.
PiperOrigin-RevId: 608660908
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
normalized timestamp.
Without this change, an input of `9223372036854775807, 2` leads to a java.lang.ArithmeticException: overflow.
PiperOrigin-RevId: 607359958
My org, as part of its reproducible-build hygiene, builds projects with the source trees in read-only mode. I approached the protobuf build in the same way, but encountered this error (among others):
```
[ 30%] Built target statusor
[ 34%] Built target libprotobuf-lite
[ 45%] Built target libprotobuf
Consolidate compiler generated dependencies of target libprotoc
[ 62%] Built target libprotoc
Consolidate compiler generated dependencies of target protoc
[ 62%] Built target protoc
Consolidate compiler generated dependencies of target scoped_mock_log
[ 62%] Built target scoped_mock_log
[ 62%] Generating /home/src/protobuf/src/google/protobuf/util/message_differencer_unittest_proto3.pb.h, /home/src/protobuf/src/google/protobuf/util/message_differencer_unittest_proto3.pb.cc
/home/src/protobuf/src/google/protobuf/util/message_differencer_unittest_proto3.pb.cc: Read-only file system
make[2]: *** [CMakeFiles/libtest_common.dir/build.make:387: /home/src/protobuf/src/google/protobuf/util/message_differencer_unittest_proto3.pb.h] Error 1
make[1]: *** [CMakeFiles/Makefile2:1194: CMakeFiles/libtest_common.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
```
(`/home/src` is a read-only mount)
Generated source files are effectively build artifacts, and should be written to the build tree, not the source tree. This PR accordingly enables a successful build and test run (lite, full, and conformance) with read-only sources.
(Beyond this, I would add that CMake usually does not need source file paths to be qualified with `CMAKE_SOURCE_DIR` or `CMAKE_BINARY_DIR`; in most cases it knows to look in both locations, favoring the latter if a file is in both. The CMake code could be simplified by relying on this behavior.)
Closes#14455
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14455 from iskunk:feature/ro-source da7510c24a
PiperOrigin-RevId: 607031010
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
WriteDictionary does not pass indentationLevel downwards to WriteValue. The existing test for `MapField` only tests `MapField<string, string>`, which isn't affected by the issue.
Tests are added for this issue.
Note: I also added `WriteValueWithIndentation_MapWithEmptyNested` to ensure this change would break things, but I doubt if it's necessary. Let me know whether to remove it.
Closes#15836
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15836 from q42jaap:main 2b9399ba0c
PiperOrigin-RevId: 607000434