tree 499058459228a60fa440563e6380f5790a6ddf9f
parent 2feb36fc51e085040d7978f919f0dcf9a14a2b5f
author adonovan <adonovan@google.com> 1584741474 -0700
committer Copybara-Service <copybara-worker@google.com> 1584741543 -0700

bazel packages: record Starlark stack in RuleClass at creation

This change does three things:
1) reduces the space used by instances of Rule, which are numerous;
2) causes RuleClass instances to record the Starlark stack upon creation;
3) reports the RuleClass stack in query --output=build.

The motivation for this change was to remove a field from class Rule to
nullify the space increase of the Rule.callstack field added to support
the --record_rule_instantiation_callstack feature. The removed field,
Rule.definitionInformation, provided debugging information for certain
errors, such as a repo cycle; notably it was a pile of text, and was
populated only for repository rules. It did not warrant a field in such
a high-cardinality object.

Now, the same debugging information is provided by computing it on the
fly from structured information: Rule.callstack and RuleClass.callstack.
In addition, RuleClass.callstack is reported to users through query.

This requires that we record stacks not just for rule instantiation
(added in commit 40a737c8f369270490e00b69d98c8c8ea31ff697 / commit 40a737c, subject to --record_rule_instantiation_callstack),
but also for their RuleClass declarations, which we now do unconditionally.

Details:
- plumb (semantics, callstack) to rule instantiation instead of (@Nullable thread, location).
- inline BRF.addRule, WFH.createAndAddRepositoryRule.
- eliminate location parameter to WFH.addRepoMappings, fix unsafe cast, and test.
- improve the format of the "definition information" pile of text so that it
  includes both stacks. (Given than no-one cared enough about it to bother adding
  a test, this is probably wasted effort and a good deed that will be punished.)
- RuleClass.callstack is not currently subject to serialization.

One behavior change: The location associated with a repository rule was formerly
that of the innermost call at instantiation. Now, because the call stack is plumbed
down to createRule, both rule.location and generator.location are set to the outermost
call, just as ordinary package rules have behaved since Google Issue 23974287 was
fixed in 2015 (CL 103004059 / commit 0cb41b0).

RELNOTES:
'query --output=build' now shows where rule classes (not just rules) are created.

The location associated with a repository rule is now that of the
outermost function call at instantiation, not the innermost call.

PiperOrigin-RevId: 302105043