The change is no-op for Bazel < 8, it always falls back to native providers.
When we cherry-pick --incompatible_autoload_externally to older Bazels, ProtoInfo
can be replaced with Starlark implementation, providing that users set the flag so that there is no second implementation exposed from Bazel.
PiperOrigin-RevId: 674561141
Bazel 6 falls back to native rules, because of ProtoInfo differences.
Bazel 7 is slightly degraded: Kythe flags don't work, DebugContext is left out from CcInfo and temporary files generated by the C++ compiler (but it's only useful for debugging).
Tests will be submitted in separate PRs.
PiperOrigin-RevId: 674030212
This CL is mostly a no-op, except that now google3-only code is actually stripped from OSS, instead of being preserved in `# begin:google_only` blocks.
This follows the conventions of the greater Copybara ecosystem.
PiperOrigin-RevId: 669513564
This simplifies upb by removing differences between google3 and OSS.
This also points upb at the protobuf license, instead of keeping a separate copy around for upb.
PiperOrigin-RevId: 669447145
The toolchain type is consumed by proto_library and produced by proto_toolchain rule. As such it's a private dependency, because both rules are now part of protobuf repo.
There are some early adopters of --incompatible_enable_proto_toolchain_resolution that might be broken from this: grpc, rules_go, rules_ts, rules_rust, rules_lint, because they have implementation that is not using proto_common. Those repositories need to define their own proto_lang_toolchain and consume it with proto_common.compile.
PiperOrigin-RevId: 654897871
Use paths.is_normalized and paths.is_absolute from bazel skylib. Upgrade skylib to latest version that has the implementation.
Use copybara for the differences in STRIC_DEPS_FLAG_TEMPLATE.
Implement native_bool_flag to read native flags and use them in proto_library. Those are implemented in such a way, that they can be replaced in place with starlark bool_flag targets.
Implement version check for PackageSpecificationInfo. It's only available after Bazel 6.4.0.
Tests will be submitted in separate PRs.
PiperOrigin-RevId: 653532601
Enable the Starlark rule only on Bazel versions, that have the Starlark version of ProtoInfo provider. That's needed, because only that exposed _transitive_proto_info field that's used in the rule.
PiperOrigin-RevId: 651753437
Rewrite compile tests from BazelProtoCommonTest to Starlark. This is using rules_analysis for testing.
The tests are super fast (cca. 1s for all of the to run).
The tests work either with a redirect (calling native rule) or with actual implementation in the protobuf repository.
PiperOrigin-RevId: 651748083
Move toolchain helpers into a separate private file. After the migration those should be removed, so let's not make it a new public APIs. Copybara also handles differences in toolchain type labels.
Remove ProtoLangToolchainInfo from proto_common. Providers need special care when moving and will be moved last.
Read INCOMPATIBLE_ENABLE_PROTO_TOOLCHAIN_RESOLUTION from native proto_common. This is a BuildLanguageConfiguration flag (load time flag) and may only be read through native support. Add a dependency to the latest bazel_features that supports this check. On older Bazel versions fail if ALLOWLIST is configured.
Implement version check for PackageSpecificationInfo. It's only available after Bazel 6.4.0.
The rest of the implementation matches Bazel version. Tests are quite extensive and will be submitted in separate PRs.
PiperOrigin-RevId: 651699412
The functionality is enabled when the proto_one_output_per_message option used by C++ Lite is enabled.
This mirrors the behavior of C++ lite protos.
PiperOrigin-RevId: 642327960
The functionality is enabled when the `proto_one_output_per_message` option used by C++ Lite is enabled.
This mirrors the behavior of C++ lite protos.
PiperOrigin-RevId: 640592937
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
This is needed to make protobuf/bazel package minimal for other proto rules.
Keep 4 public bzl files in upb/bazel. They end up under protobuf/bazel, and they are legitimately used by other repositories.
Move upb_proto_library_internal/* under bazel/private. Those are utilities used in the rules. Moving them one level deeper makes protobuf/bazel package clean for other rules.
Move build_defs.bzl and amalgamation under /upb/bazel. Those are utilities used in the build.
Move lua.BUILD and python* uner /python/dist. Those are used in the WORKSPACE dependency setup.
PiperOrigin-RevId: 621442236
Three of these runtimes are based on upb, and the fourth is based on the Java runtime. Both of these already have editions support, so this was mostly just a matter of:
- Advertising support to allow editions codegen
- Stripping features from the runtime options
- Hooking up conformance tests
- Adding some lightweight editions tests
There are also a few minor orthogonal fixes included here:
- Ruby's upb hack for treating all enums as open enums needed tweaking
- The `enable_editions` flag is no longer needed in our internal proto rules
PiperOrigin-RevId: 616256211
This now matches the upb_use_cpp_toolchain function name in the equivalent function in third_party/upb/bazel/upb_proto_library_internal/cc_library_func.bzl.
PiperOrigin-RevId: 606257428
To satisfy the layering check, we need to depend on :gtest for the headers, in
addition to :gtest_main which provides the main() function.
There are a bunch of formatting changes as a side effect of this, but they
should be harmless.
PiperOrigin-RevId: 594318263
This makes the file layout a bit more consistent with the `protos ->
protos_generator` pattern. I also replaced the `upbc` namespace with
`upb::generator`.
PiperOrigin-RevId: 569264372
This separate helper for upb dependencies no longer makes sense now that upb
has been merged into the protobuf repo. This change deletes that helper and
moves the upb-specific dependencies into the `protobuf_deps()` function.
I noticed that the Python package deps need to be updated to reflect our
current support level, but I will fix that in a followup CL.
PiperOrigin-RevId: 568997625
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
Protobuf Team Bot
Jingwen Chen
Eric Salo
Joshua Haberman
Alex Eagle
Sandy Zhang
Tiago Quelhas
Mike Kruskal
Adam Cozzette
Richard Levasseur
xiaolou86