next available enum number in addition to mentioning the option to allow
aliasing.
For enums that are large but are not sorted numerically it can be difficult to
find the correct enum number to use.
We use "next available" as the next number larger than the number that was
duplicatively used which is not assigned a value. For sparse enums, there may
be other enums past the suggested number.
PiperOrigin-RevId: 523487238
In this CL I'd like to call existing C++ Protobuf API from the V0 Rust API. Since parts of the C++ API are defined inline and using (obviously) C++ name mangling, we need to create a "thunks.cc" file that:
1) Generates code for C++ API function we use from Rust
2) Exposes these functions without any name mangling (meaning using `extern "C"`)
In this CL we add Bazel logic to generate "thunks" file, compile it, and propagate its object to linking. We also add logic to protoc to generate this "thunks" file.
The protoc logic is rather rudimentary still. I hope to focus on protoc code quality in my followup work on V0 Rust API using C++ kernel.
PiperOrigin-RevId: 523479839
unknown and the key has the high bit on.
It was being serialized as signed, which caused it to be sign extended. The
value is equivalent after parsing as 32-bit, but it is inconsistent with other forms of
serialization.
PiperOrigin-RevId: 523428645
This can be useful when an extension field/declaration is deleted in schema to avoid data corruption.
It also adds a check for duplicate numbers in the declarations.
PiperOrigin-RevId: 523269837
This change improves deserialization performance by in two ways:
1) VarintParseSlowArm32 and VarintParseSlowArm64 return a pair for the updated buffer pointer and parsing result instead of storing the result and returning just the pointer. This allows the parsed result to be returned to higher level code in x1 rather than via the stack.
2) Remove prohibition on inlining VarintParseSlowArm32 and VarintParseSlowArm64. This prohibition was originally included to avoid bloating non-TDP code. Now that TDP is enabled the impact on code size is small.
PiperOrigin-RevId: 523142512
This turns out to be quite of a yak shave to be able to perfectly test both kernels without having to pass extra Blaze flags.
PiperOrigin-RevId: 521850709
This change improves deserialization performance by in two ways:
1) VarintParseSlowArm32 and VarintParseSlowArm64 return a pair for the updated buffer pointer and parsing result instead of storing the result and returning just the pointer. This allows the parsed result to be returned to higher level code in x1 rather than via the stack.
2) Remove prohibition on inlining VarintParseSlowArm32 and VarintParseSlowArm64. This prohibition was originally included to avoid bloating non-TDP code. Now that TDP is enabled the impact on code size is small.
PiperOrigin-RevId: 520985945
We intended to use these for our release page, but we instead removed language-specific source files and use github commands to generate the full zip/tar file we release.
PiperOrigin-RevId: 520979818
The idea is that after this refactoring we implement the codegen for field accessors by adding another template variable, like
p.Emit(
...
$ImplMessageFunctions$;
$ImplFieldAccessors$;
...
)
PiperOrigin-RevId: 520571021
Syntax will become meaningless once we migrate to editions. In the meantime, we've implemented APIs to expose the differences between proto2 and proto3 in terms of the features we plan to release in edition 2023.
PiperOrigin-RevId: 520433607
Marcel Hlopko
Jakob Buchgraber
Protobuf Team Bot
Protobuf Team Bot
Sandy Zhang
chandlerc
Romfos
Jie Luo
Adam Cozzette
Joshua Haberman
Mike Kruskal
Deanna Garcia
Martijn Vels
Augie Fackler