commit | ebb86fcdc202c440a362a54f6b0de8a049dfa84b | [log] [tgz] |
---|---|---|
author | adonovan <adonovan@google.com> | Fri Mar 20 14:57:54 2020 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Fri Mar 20 14:59:03 2020 -0700 |
tree | 499058459228a60fa440563e6380f5790a6ddf9f | |
parent | 2feb36fc51e085040d7978f919f0dcf9a14a2b5f [diff] |
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
{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:
See CONTRIBUTING.md