We reserved a range of 10 a couple of years ago but are nearing exhausting that block. We anticipate needing to define more custom options, so this allocates another block of numbers to Buf.
Closes#18548
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18548 from jhump:jh/more-option-numbers 898fdec6db
PiperOrigin-RevId: 680810934
We generate these constants to enable map operations, but this is no longer
necessary now that we can get the relevant size and alignment information for
each message through its vtable.
PiperOrigin-RevId: 680712939
Protobuf uses utf8_range library for utf8 string validation.
Currently, only SSE implementation is integrated.
This patch adapts utf8_range Neon implementation to protobuf.
Closes#18126
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18126 from cyb70289:utf8-neon 5edbcc2692
PiperOrigin-RevId: 680711032
add the traits for their dependencies.
Move StrongPointerToType to the new traits and remove the old codegen for it.
We will extend these traits to contain more information.
PiperOrigin-RevId: 680562664
Functions like `map_get` return a rust Option, which
might conflict with a `message Option` defined in the
current proto file. Use `::__std::option::Option` to
disambiguate rust Option and message Option.
PiperOrigin-RevId: 680333636
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