This yields several benefits:
1. The code no longer needs to be bootstrapped (since it no longer depends on upb reflection).
2. The upb code generator no longer depends on libprotobuf at all (except for `code_generator_lite.{h,cc}`, which is just one .cc file and has no deps).
PiperOrigin-RevId: 672280579
This installs a upb's static library, headers, and three protoc plugin binaries (upb, upbdefs, upb_minitable). These will now be enabled by default, but can be disabled by setting protobuf_BUILD_LIBUPB=OFF.
To qualify this, we hook into our existing install test infrastructure which attempts to build and run our tests without any of the installation artifacts available from the source tree. Public headers are deleted, and builds of exported libraries/binaries are disabled.
PiperOrigin-RevId: 617376961
Until recently, these targets were dependencies of `//:protobuf` and could thus
be accessed through that target. But now that we are adhering to the layering
check, we need to provide proper access in a way that respects that check. This
change uses top-level alias targets following the existing pattern.
PiperOrigin-RevId: 605123979
This check enforces that each C++ build target has the correct dependencies for
all headers that it includes. We have many targets that were not correct with
respect to this check, so I fixed them up.
I also cleaned up the C++ targets related to the well-known types. I created a
cc_proto_library() target for each one and removed the :wkt_cc_protos target,
since this was necessary to satisfy the layering check. I deleted the
//src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt,
because the distinction between the :protobuf and :protobuf_nowkt targets was
not really correct. Neither one exposed the headers for the well-known types in
a way that was valid with respect to the layering check, and the idea of
bundling all the well-known types together is not idiomatic in Bazel anyway.
This is a breaking change, because the //:protobuf target no longer bundles the
well-known types. From now on they should be accessed through the new
//:*_cc_proto aliases in our top-level package.
I renamed the :port_def target to :port, which simplifies things a bit by
matching our internal name.
The original motivation for this change was that to move utf8_range onto our CI
infrastructure, we needed to make its dependency rules_fuzzing compatible with
Bazel 6. The rules_fuzzing project builds with the layering check, and I found
that the process of upgrading it to Bazel 6 made it take a dependency on
protobuf, which caused it to break due to layering violations. I was able to
work around this, but it would still be nice to comply with the layering check
so that we don't have to worry about this kind of thing in the future.
PiperOrigin-RevId: 595516736
This makes third_party/utf8_range no longer a Git subtree, but instead the
permanent location and source of truth for utf8_range. It is also now
incorporated into the @com_google_protobuf Bazel repo. Utf8_range still has its
own separate CMake build for now, though.
PiperOrigin-RevId: 580682733
Our stale file regeneration logic broke with Bazel 6.4.0, and I suspect it was
caused by this change: https://github.com/bazelbuild/bazel/pull/19534 Our logic
assumed that any target with a `CcInfo` provider must have `hdrs` and
`textual_hdrs` attributes, but it seems that this is no longer true for
`cc_proto_library` starting with Bazel 6.4.0. The fix is just to use `getattr`
and treat the item as an empty list if it's missing.
PiperOrigin-RevId: 575473886
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
This is some low hanging fruit that can increase our test coverage of editions. Since only the C++ backend is implemented today, we can't yet migrate any protos that are public, are used outside C++, or are depended on by any proto outside C++.
PiperOrigin-RevId: 546076822
This represents the future direction of protobuf, replacing proto2/proto3 syntax with editions. These will enable more incremental evolution of protobuf APIs through features, which are individual behaviors (such as whether field presence is explicit or implicit). For more details see https://protobuf.dev/editions/overview/.
This PR contains a working implementation of editions for the protoc frontend and C++ code generation, along with various infrastructure improvements to support it. It gives early access for anyone who wants to a preview of editions, but has no effect on proto2/proto3 syntax. It is flag-guarded behind the `--experimental_editions` flag, and is an experimental feature with no guarantees.
PiperOrigin-RevId: 544805690
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
After this change, the Rust codegen can be enabled via the protoc flag '--rust_out'. Due to its experimental nature we require a magic value to be provided '--rust_out=experimental-codegen=enabled:<out>'.
Make the 'RustGenerator' create an empty *.pb.rs file.
PiperOrigin-RevId: 512644570
I updated our Bazel CI jobs to cover `//pkg/...` and thereby exercise this new
test. That made me realize that `//pkg/...` was not fully buildable because
there was a reference to the non-existent target `@utf8_range//:dist_files`, so
I also fixed that.
PiperOrigin-RevId: 498437497
It looks like Bazel 6.0 changed the stringification of Label objects:
b1113f801d
That is causing some problems for our staleness test, since different
Bazel versions get different results. This CL fixes the problem by
tweaking the logic so that we explicitly format the label string.
PiperOrigin-RevId: 496790722
Joshua Haberman
Hong Shin
Mike Kruskal
Protobuf Team Bot
Sandy Zhang
aiuto
Adam Cozzette
Marcel Hlopko
Martijn Vels
Joshua Haberman
Deanna Garcia
deannagarcia
Jakob Buchgraber
archpaleus