If this code is in every method, it's making every method larger, putting
pressure on the instruction cache.
The string formatting is an exceptional case that shouldn't slow down the
regular case.
This should modestly speed up the code in here. And besides, it's just a little
nicer to have this formatting centralised.
PiperOrigin-RevId: 679336304
This will simplify runtime code that wants to access and use the structures.
This is a refactor with no expected behavior change.
PiperOrigin-RevId: 679316372
Move hpb::internal::{Serialize, HasExtensionOrUnknown, GetOrPromoteExtension, DeepCopy, DeepClone} to message_lock.h as they all use the message lock
absl status helpers are now housed in status.h
PiperOrigin-RevId: 679307322
Github dropped support for the current image:
https://github.com/actions/runner-images/issues/10559
There is a new image that has visionOS, but it is listed as
"beta", so it might make sense to wait and revisit when
generally updating the macOS images/tools.
PiperOrigin-RevId: 679264196
On Android, this generates better assembly code, bounds-checking through all
the used indices upfront, and branching to deoptimise if it's not true,
avoiding doing 4x bounds checks. We also don't generate 4 different
`pThrowArrayBounds` code sections.
https://godbolt.org/z/Kbhvcdvbd
Code size Comparison:
- `void X.writeFixed32NoTag__before(int) [292 bytes]`
- `void X.writeFixed32NoTag__after(int) [180 bytes]`
This starts by throwing a more meaningful length (4bytes or 8bytes for fixed64), which makes sure the value of position in the catch clause isn't dependent on which line threw the exception.
PiperOrigin-RevId: 678543462
The rules in protobuf and built-in Bazel don't mix well. Different aspects may cause actions conflicts. The safest way is to use built-in rules whenever they are still present.
proto_library should be safe, because it's not using an aspect. py_proto_library never had a built-in implementation, so it's also safe.
This still makes it possible to use the rules on Bazel 7, but only with --incompatible_autoload_externally enabled.
PiperOrigin-RevId: 678446311
The source was becoming unmanageable at ~3500 LOC. It was also cumbersome to run just the `RepeatedField` or `RepeatedPtrField` subset of tests after modifying their respective implementations in the respective sources.
PiperOrigin-RevId: 678439322
For cross-compilation, we may not want to re-use the same protoc which would be used during a CMake build (these would differ in hostPlatform).
Instead, allow for invocations of `protobuf_generate` pass their preferred programs, similar to how you can do this for grpc plugins.
Optional proposal:
Use `find_program`, however, this is a pretty big behavior change, this PR allows you to "opt-out" of the legacy behavior, but users shouldn't see a difference unless they opt-in to passing their own protoc-exe command/path
Closes#17888
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17888 from jonringer:configure-protoc-cmake 9ca38aee11
PiperOrigin-RevId: 678383523
This came up as a pull request here:
https://github.com/protocolbuffers/protobuf/pull/18239.
|tmpnam| is ugly and would be nice to avoid.
We don't necessarily want to substitute out GetTemporaryDirectoryName with
|std::filesystem::temp_directory_path| -- the current setup creates a
subdirectory under the tmp directory and uses TempDirDeleter to clean it up.
We want to preserve that behaviour: the current setup plays nicely with bazel
without polluting /tmp with unbounded growth.
#test-continuous
PiperOrigin-RevId: 677843997
The immediate motivation for this is that it will facilitate writing a blanket
implementation of `ProxiedInMapValue` for C++-backed messages. The default
instance gives us access to the message vtable in cases where we don't already
have a message to work with.
However, it also seems generally useful just to have an implementation of
`Default`, so I implemented it for both C++ and upb-backed message views.
PiperOrigin-RevId: 677808048
This was untested before.
Some of the test names had drifted from the code's names; update those.
These tests have surfaced some problems around inconsistent exception types thrown.
PiperOrigin-RevId: 677588477
These tests were (generally) looping over OutputType already. Some tests were looping over a subset; I've expanded many tests to loop over more OutputTypes.
But the first failure they encountered with any OutputType meant they'd halt
that test, without testing the other OutputTypes. That's frustrating.
We use `assume()` to discard tests in the matrix that are irrelevant.
There are many java parameterized test runners. I followed the lead of
third_party/java_src/protobuf/current/javatests/com/google/protobuf/IsValidUtf8FourByteTest.java,
which uses Paramaterized runner.
This means:
- We see which output type is failing in the test name.
- We don't have to always assertWithMessage(OutputType.name()). We can just use
assertThat. Nice.
- It's really easy to add new coders, and run all the tests against them. I've
done that here for NIO encoders with offset, increasing their test coverage.
PiperOrigin-RevId: 677564209
This makes it clearer that we get the arguments around the right way, so the error messages make sense.
Also get rid of toList; it doesn't seem necessary, the Truth library can compare byte[]s just fine without first turning them into List<Byte>.
This is just a refactoring to make this test nicer before I add more tests covering out of space scenarios.
PiperOrigin-RevId: 676963220
Also, change the proto used in no_field_presence_map_test into its own proto.
This should result in cleaner more isolated tests.
No other changes (other than autoformatter removing unused definitions).
PiperOrigin-RevId: 676927081
This was mistakenly gated on edition and only applied to proto2/proto3 and edition 2023.
This also cleans up some of our validation logic for ctype/string_type. Similar to other language features, ctype will only be validated by the C++ generator. This means that protos that aren't used in C++ may end up with ctype incorrectly specified, but our Prototiller transformation for 2024 will strip those anyway (since we ban ctype in 2024).
PiperOrigin-RevId: 676893004
While in practice a C++ ref and ptr will have the same ABI, since C doesn't have refs this gets flagged by -Wreturn-type-c-linkage. Note that this contrasts with the Rust side where C-ABI functions that take a pointer or ref are permitted and guaranteed to have the same ABI.
PiperOrigin-RevId: 676875775