commit 8be3468c9b16ee8ec436628827f3443674b7b70d
author Googler <noreply@google.com> Mon Sep 23 11:31:14 2019 -0700
committer Copybara-Service <copybara-worker@google.com> Mon Sep 23 11:32:19 2019 -0700
tree b982bbe185f9aff31511c71c96712c09ee3d866d
parent 67fa629762aa9e6a50679605d0873ca0397b18ed

bazel syntax: move Environment.callerLabel to BazelStarlarkContext.analysisRuleLabel

BazelStarlarkContext is the application state carried by each Starlark thread
created by Bazel/Blaze, and is thus the logical place to hold this information.

The callerLabel field exists only to support the legacy behavior of
Label(relative_to_caller_repository=True), which causes a label string to be
parsed relative to the repository of the rule being analyzed; the default
behavior is to use repository of the file containing the call to Label.

Aside: the deprecated semantics are actually cleaner, since they rely only on
state---analysisRuleLabel---in the Starlark thread. By contrast, the supported
semantics are more complex and subtle because they rely on dynamic scope:
in effect, they introspect on the call stack and use the Label associated with
the topmost file. Dynamic scope has been recognized as a mistake for over 50 years.

The analysisRuleLabel field is set only for analysis-phase (rule and aspect
implementation) Starlark threads, and is the label of the rule instance.
(Previously, setCallerLabel was done only for rule implementation threads,
not aspect threads, but I suspect this was an oversight, so I made them
consistent.)

The motivation for this change is to eliminate Environment.getCallerLabel,
thus breaking a dependency from Environment to Label.

Also: remove a use of getCallerLabel in the android rules. I made it use
ruleContext.getLabel, which is consistent with other places in the android
rules. I suspect that someone grabbed this function by mistake while blindly
groping for anything that would give them a Label.

Also: remove obfuscating "convenience" constructor of BazelStarlarkContext.
It's much clearer to have one constructor with lots of /*foo=*/null arguments
at each call than to have two or more constructors that are hard to tell apart
and impossible to remember.

Also: document some of the problems with the Label function.

Once unknown commit is also submitted, we can delete Environment.callerLabel.

PiperOrigin-RevId: 270722058