It seems that some files that are generated by the compiler for tests aren't ignored correctly. So I always get the untracked files when I run the tests.
59a8de6610/ruby/Rakefile (L23-L39)
This PR ignores those files to avoid treating them as untracked files.
Closes#19670
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19670 from y-yagi:ignore_generated_files 2a93c59652
PiperOrigin-RevId: 706847541
Before this change, hpb had no way of returning repeated fields (that are extensions) -- they were incorrectly treated as pure scalars (int32 vs repeated<int32>).
We rectify this hole and now return RepeatedField<T> for a given T.
This CL also cleans up the `if constexpr` special casing we were performing inside GetExtension and delegates that to the UpbExtensionTrait.
PiperOrigin-RevId: 706789273
It's not yet possible to import any of the well-known types from a proto file
in another crate. To enable this I think we'll need to generate a function that
dependent crates can call to determine the directory that contains the
well-known types.
PiperOrigin-RevId: 706745114
This is mostly a style fix so that we can avoid using decltype which is a bit
cumbersome. auto template arguments is a C++17 feature so we can only do this
after we've migrated the buildchain to use C++17.
We upgraded main branch to C++17 in commit
fe535930d3
PiperOrigin-RevId: 706015756
The main branch was upgraded to use C++17 after the 29.0 branch cut, in commit
fe535930d3
There are still stale references to C++14 in the code, build chain, and
READMEs. This commit cleans up the stale configs and settings.
PiperOrigin-RevId: 706000867
Proto file paths generally need to be globally unique, or at least unique
within the same binary. A file conflict might be tolerated in protobuf
implementations without reflection, but ones that do support reflection will
have trouble building a descriptor pool that has one more than one proto file
with the same path.
This change therefore updates the example crate to put the proto files inside a
`proto_example/` directory since this lessens the chance of a conflict. Not
that we really care about the example crate conflicting with anything, but I
think this makes it a better example to follow.
PiperOrigin-RevId: 705982825
I also added a check to ensure that `protoc --version` matches the protobuf
runtime version. The minitable generator plugin version should also match, but
unfortunately we can't easily check this today because it does not provide a
way to check its version.
PiperOrigin-RevId: 705944904
The specific format is something which you could more easily copy-paste back into a test, either:
`SomeEnumName::CorrespondingNamedConstant` or
`SomeEnumName::from(someint)` for open enums with an unrecognized value.
For now this is emitting the string literals for the names in a generated match statement in .rs; this makes it work for both cpp and upb kernels, as well as hopefully reduces bloat if there is no cross-language lto.
At a future time we could consider calling into C++ to get the enum names there, which is a more optimized path and could reduce having the names in the binary twice in some cases.
PiperOrigin-RevId: 705910092
== Functionality ==
Given a Rust function signature `pub fn handle_request(&mut self, req: FooRequestView, mut rsp: FooResponseMut) -> bool`, where `FooRequestView` and `FooResponseMut` are Protobuf Rust proxy types. This change enables Crubit to generate C++ bindings for `handle_request` with the C++ function signature `bool handle_request(const FooRequest* req, FooResponse* rsp)`.
== Crubit changes ==
Within a blaze build the Protobuf generated crate has two names. When the generated code gets compiled the name of the crate is the name of the `proto_library`. Later in the build the crate is renamed to the name of the `rust_proto_library`, which is what developers using Rust Protobufs see. So when the `cc_bindings_from_rs_aspect` runs the name of a Protobuf crate is the name of the `proto_library` and when the Crubit bindings get compiled the Protobuf crate in its dependencies has the name of the `rust_proto_library`. Therefore, in Crubit's generated code we rename the crate to its proto_library name via `extern crate` statements. We pass this information to Crubit via cmdline flag that gets set from within the build rules.
== Protobuf Rust changes ==
When building for the C++ kernel, Protobuf Rust View and Mut types get annotated with the `__crubit::annotate` attribute. The attribute describes the C++
message type to which the Rust type should be converted and it also includes the header that declares the C++ message type. Additionally, the type is marked `repr(transparent)` so that Crubit can verify that the ABI layout of a Protobuf Rust proxy type is pointer-like i.e. the view/mut structs have a single pointer field and any number of ZSTs. With this knowledge Crubit can generate code to convert the pointer-like Rust struct to a C++ pointer (and vice versa). No explicit conversion functions need to be specified.
An example of an annotation:
```
#[__crubit::annotate(
cpp_type = "const FooRequest*",
cpp_type_include = "path/to/foo_request.proto.h",
)]
#[repr(transparent)]
struct FooRequestView { ... }
```
PiperOrigin-RevId: 705850175
The previous treatment was a conformance violation, where implicit present float fields with a non-default value of -0.0 could get dropped.
PiperOrigin-RevId: 705728806
Also update the protobuf_example crate to use the OUT_DIR instead of the source in the /src dir.
This will avoids problems of the outdir having stale files that shouldn't be there anymore still being picked up in the build.
PiperOrigin-RevId: 705609005
This brings it into conformance with our spec and other languages. Some parse paths already did this check, and all of them prohibit *nested* unmatched end-group tags.
PiperOrigin-RevId: 705225060
This is only used in some narrow edge cases, and is a less-safe version of our unknown field decoders. Switching to those reduces some duplication and improves error handling.
PiperOrigin-RevId: 704899254