Add rule class definitions to query proto output

As rules are starlarkified and migrated out of Bazel, tools cannot rely any
longer on the (undocumented and deprecated) `info build-language` output to find
the definitions of rule classes. Moreover, the name of the rule class is no
longer unique: two different .bzl files might define different rule classes with
the same name - and both might be used in the same package.

For starlarkified rules, tools could use `starlark_doc_extract` targets to get
the rule class definition in proto form. However, this requires
(1) knowing in advance which .bzl file to introspect
(2) adding a `starlark_doc_extract` target to perform this introspection.

This is obviously not ideal when a tool needs to introspect targets without
changing the state of a repo.

The solution is to add `starlark_doc_extract`-like rule class definitions to
`query` command output. Since a RuleInfo proto (the rule class definition as
output by starlark_doc_extract and Stardoc) is large and expensive to generate,
we want to
* only output it optionally, when --proto:rule_classes flag is set
* only output each rule class definition once per output stream - in the first
  rule target having a given rule class key.
* add a rule class key, unique per rule class definition (not just rule class
  name!), so that later rule targets in the stream with the same rule class
  definition can be connected with the rule class definition provided in the first
  target.

RELNOTES: If --proto:rule_classes flag is enabled, query proto output will contain rule class definitions in Stardoc proto format.
PiperOrigin-RevId: 680642590
Change-Id: Ibdeb9c8acb7368b510f62d945c361a86cdb6f447
6 files changed
tree: db5558e7f2681b416c9bc9dfce3f10d391aaf895
  1. .bazelci/
  2. .github/
  3. examples/
  4. scripts/
  5. site/
  6. src/
  7. third_party/
  8. tools/
  9. .bazelrc
  10. .bazelversion
  11. .gitattributes
  12. .gitignore
  13. AUTHORS
  14. bazel_downloader.cfg
  15. BUILD
  16. CHANGELOG.md
  17. CODE_OF_CONDUCT.md
  18. CODEOWNERS
  19. combine_distfiles.py
  20. combine_distfiles_to_tar.sh
  21. compile.sh
  22. CONTRIBUTING.md
  23. CONTRIBUTORS
  24. distdir.bzl
  25. extensions.bzl
  26. LICENSE
  27. maven_install.json
  28. MODULE.bazel
  29. MODULE.bazel.lock
  30. rbe_extension.bzl
  31. README.md
  32. repositories.bzl
  33. requirements.txt
  34. SECURITY.md
  35. WORKSPACE.bzlmod
  36. workspace_deps.bzl
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status