Refactor retrieval of BazelModuleContext from thread, and @_builtins allowlist checking

Most of the call sites inspecting the Starlark stack (Module.ofInnermostEnclosingStarlarkFunction) are to check whether we're in the @_builtins repo or another allowlisted location. Direct use of stack inspection is discouraged, so this CL refactors these usages into helpers underneath the existing BuiltinRestriction utility class.

The delta ended up being much bigger than I intended, but most of the change is straightforward-ish.

- BazelModuleContext: of() is now explicitly documented as returning null if there's no applicable context object, and no longer crashes if the context object is of the wrong type. Added ofInnermostBzlOrThrow() to serve the common case of retrieving a context from a given thread and throwing an unchecked exception if there is none.

- Factored a bunch of "check where we're called from, fail if it's not @_builtins" implementations into BuiltinRestriction.throwIfNotBuiltinUsage, which is renamed to failIfCalledOutsideBuiltins. (The "fail" terminology is more idiomatic when we're talking about a soft Starlark evaluation error rather than a fatal exception.) The error message is tweaked to mention the offending .bzl file. In one or two cases we now omit the name of the guarded api.

- Factored similar checks that allow either @_builtins or an allowlist into BuiltinRestriction.failIfCalledOutsideAllowlist.

- In some cases matching logic is changed to "is a subpackage of" rather than "package matches exactly". In others it changed from "is a string prefix of" to "is a package prefix of". One instance of the dummy name //bazel_internal/test was changed to //bazel_internal/test_rules for this reason.

- CcModule had the most elaborate allowlist checking. It needs to work under bzlmod, so some allowlist items need to be processed through the repository mapping. I refactored it so that instead of creating non-canonically named PackageIdentifiers (which violates the invariant that instances of Label, RepositoryName, etc., should always be canonical), the allowlist is written as a list of strings and parsed into PackageIdentifiers when needed.

- Created BuiltinRestriction.failIfLabelOutsideAllowlist for the few cases where we want to compare the allowlist against a stack frame that is not the top-most frame.

- Fix typo in test case names

- Drive-by fix: Added BazelModuleContext#ofInnermostBzlOrFail and use it in Label() constructor, so that calling Label() inside a BUILD file does not crash.

PiperOrigin-RevId: 555236616
Change-Id: If1f830e316fef056a7d722c8891a0017663e95a2
33 files changed
tree: 3bd051064dd8c5611ae59d482d765f3963061da4
  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. BUILD
  15. CHANGELOG.md
  16. CODE_OF_CONDUCT.md
  17. CODEOWNERS
  18. combine_distfiles.py
  19. combine_distfiles_to_tar.sh
  20. compile.sh
  21. CONTRIBUTING.md
  22. CONTRIBUTORS
  23. distdir.bzl
  24. distdir_deps.bzl
  25. extensions.bzl
  26. LICENSE
  27. maven_install.json
  28. MODULE.bazel
  29. rbe_extension.bzl
  30. README.md
  31. repositories.bzl
  32. requirements.txt
  33. SECURITY.md
  34. WORKSPACE
  35. WORKSPACE.bzlmod
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