tree 1fd0996e746cfc83435c701c63a2262fc133aa49
parent 44dd49469d9fe1382892d2eecb87074ed8d2c6cb
author Googler <brandjon@google.com> 1714759067 -0700
committer Copybara-Service <copybara-worker@google.com> 1714759160 -0700

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