| commit | d4f30a671787b8b96824c05df9ba037782cd7f4f | [log] [tgz] |
|---|---|---|
| author | Googler <brandjon@google.com> | Fri May 03 10:57:47 2024 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri May 03 10:59:20 2024 -0700 |
| tree | 1fd0996e746cfc83435c701c63a2262fc133aa49 | |
| parent | 44dd49469d9fe1382892d2eecb87074ed8d2c6cb [diff] |
Disallow certain APIs within symbolic macros Symbolic macros are not permitted to call APIs that depend upon the order in which they are invoked relative to the rest of the package's evaluation. This rules out mutations to package-level state (other than declarations of targets), such as the `package()` callable, as well as accessors like `native.existing_rules()`. This restriction is to enable future lazy evaluation of symbolic macros, as well as general build health. The disallowed APIs are: - package(), licenses() - environment_group() - glob(), subpackages(), - existing_rule(), existing_rules() `glob()` and `subpackages()` aren't really side-effectful, but stylistically their result should be passed in as arguments, to reduce implicit entanglement between a macro definition and the package. Repo machinery APIs are also disallowed since they make no sense in the context of symbolic macros. These include: `workspace()`, `register_toolchains()`, `register_execution_platforms()`, `bind()`, and repository rule instantiation. Some of the disallowed APIs are not even currently reachable from symbolic macro implementations, because they are not available under `native` and symbolic macros can't take arbitrary arguments. We don't add tests for these situations but they are still disallowed nonetheless. Note that this CL only bans `native.existing_rules()` within symbolic macros, not legacy macros. Targets declared in a symbolic macro are visible to legacy macros via `existing_rules()`, but we intend to either change those semantics or deprecate `existing_rules()` entirely in the future. Code changes: - PackageFactory#getContext is replaced by Package.Builder#fromOrFail and a new variant, Package.Builder#fromOrFailNoSymbolicMacros. The latter is used by the disallowed APIs to produce a clean error when called inside a symbolic macro. - MacroClass#executeMacroImplementation now maintains a stack in the Package.Builder of currently executing symbolic macros. This is used by fromOrFailNoSymbolicMacros to determine whether we are inside a symbolic macro. - Deleted some unused static helpers in TargetDefinitionContext. That class is kind of unnecessary at the moment but may be useful when we move to a lazy macro evaluation implementation. - Checking for an expected error in SymbolicMacroTest is factored to a helper. Created a new helper specifically for checking errors when accessing a restricted API. Work toward #19922 PiperOrigin-RevId: 630437890 Change-Id: I010dc5f1cc47866956acc11191a5d0c81aba8a7d
{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.
Follow our tutorials:
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.
See CONTRIBUTING.md
