protobuf 30.x changes various APIs to return string_view's rather than
string&'s. This broke protobuf-c, since we were relying on the implicit
construction of strings from string&'s in various places.
This commit explicitly constructs strings from the string_view's
returned by the protobuf 30.x API when we need to store an owned string
(e.g. in a hash map). This maintains compatibility with older versions
of protobuf such as 3.21 in Debian/Ubuntu while extending compatibility
to the latest protobuf 30.x.
Without this commit we get lots of errors like this when compiling
against protobuf 30.x:
protoc-gen-c/c_field.cc:119:43: error: no match for 'operator=' (operand types are 'std::map<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >::mapped_type' {aka 'std::__cxx11::basic_string<char>'} and 'google::protobuf::internal::DescriptorStringView' {aka 'absl::debian7::string_view'})
Even though google::protobuf::internal::DescriptorStringView is exposed
in public protobuf headers, it's probably not a good idea to rely on an
"internal" typedef.
According to https://protobuf.dev/news/2024-10-02/#descriptor-apis:
v30 will update return types in descriptor (such as full_name) to be
absl::string_view.
So `absl::string_view` is probably the right type to use here.
protobuf >= 30.x replaces `const std::string&` in various APIs with
its own string view type that may actually be a `absl::string_view`.
Introduce our own `compat::StringView` type that we can use instead
of `const std::string&` in order to support compiling across multiple
protobuf versions.
If protobuf-c is already installed on the system, the cmake build can
generate an error like the following when using the ninja backend:
edmonds@chase{0}:/tmp/protobuf-c$ cmake -S build-cmake -B build -G Ninja
[...]
edmonds@chase{0}:/tmp/protobuf-c$ ninja -v -C build
ninja: Entering directory `build'
[1/19] cd /tmp/protobuf-c/build && /usr/bin/cmake -E env PATH="/tmp/protobuf-c/build:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/edmonds/bin:/home/edmonds/.cargo/bin:/sbin:/bin:/usr/games" /usr/bin/protoc --cpp_out /tmp/protobuf-c/build -I/usr/include -I/tmp/protobuf-c /tmp/protobuf-c/protobuf-c/protobuf-c.proto
FAILED: CMakeFiles/protoc-generated-files protobuf-c/protobuf-c.pb.cc protobuf-c/protobuf-c.pb.h /tmp/protobuf-c/build/CMakeFiles/protoc-generated-files /tmp/protobuf-c/build/protobuf-c/protobuf-c.pb.cc /tmp/protobuf-c/build/protobuf-c/protobuf-c.pb.h
cd /tmp/protobuf-c/build && /usr/bin/cmake -E env PATH="/tmp/protobuf-c/build:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/edmonds/bin:/home/edmonds/.cargo/bin:/sbin:/bin:/usr/games" /usr/bin/protoc --cpp_out /tmp/protobuf-c/build -I/usr/include -I/tmp/protobuf-c /tmp/protobuf-c/protobuf-c/protobuf-c.proto
/tmp/protobuf-c/protobuf-c/protobuf-c.proto: Input is shadowed in the --proto_path by "/usr/include/protobuf-c/protobuf-c.proto". Either use the latter file as your input or reorder the --proto_path so that the former file's location comes first.
[2/19] /usr/bin/cc -DPACKAGE_STRING="\"protobuf-c 1.5.0\"" -DPACKAGE_VERSION=\"1.5.0\" -I/tmp/protobuf-c -I/tmp/protobuf-c/protobuf-c -I/tmp/protobuf-c/build -MD -MT CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o -MF CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o.d -o CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o -c /tmp/protobuf-c/protobuf-c/protobuf-c.c
ninja: build stopped: subcommand failed.
Certain compilers (e.g. [0]) incorrectly generate warning messages
when the universal zero initializer is used by the protobuf-c generated
code to initialize a protobuf object containing a oneof that contains a
ProtobufCBinaryData field as the first member. This is now much more
likely due to the change in the previous commit ("protoc-c: c_message:
Order oneof union members from largest to smallest") which will now
always cause a ProtobufCBinaryData field to be placed as the first
member of the union, if one is present in the oneof.
In this situation, we need to add an extraneous pair of braces around
the universal zero initializer in the generated initialization code.
The former behavior of using the universal zero initializer by itself is
kept for oneof unions that do not contain a ProtobufCBinaryData member.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80454
This commit changes the code generator to output the members of a oneof
union from largest to smallest, rather than in field descriptor order.
This is necessary on certain compilers such as gcc >= 15 which do not
guarantee that initializing a union with the universal zero initializer
actually initializes all the bits of the object representation of the
members of the union, unless the largest union member is the first
member of the union.
- Add Ubuntu 22.04, 24.04 to the standard distcheck job.
- Add Ubuntu 22.04, 24.04 to the CMake job.
- Convert Valgrind job from Ubuntu 20.04 to 24.04.
- Convert coverage job from Ubuntu 20.04 to 24.04.
- Convert the run-on-arch-action job to run on Ubuntu 24.04 (base) and
Ubuntu 22.04 (the arch-specific actions; Ubuntu 24.04 not available).
- Add riscv64 to the list of architectures for the run-on-arch-action
job to run on.
The static library builds on Windows are throwing obscure linker errors,
but the shared library builds are succeeding, so turn off the static
library builds for now.
