commit | 9198819ef62df4a2cd670c4392078540a439964c | [log] [tgz] |
---|---|---|
author | brandjon <brandjon@google.com> | Thu May 28 14:57:45 2020 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Thu May 28 14:58:55 2020 -0700 |
tree | 559e0e9d3a4138e2f6b6392e9afbd117699b2912 | |
parent | bb6ecd71d47f393db703ba96f9e28c557eb224cc [diff] |
Refactor and document the BzlLoadFunction inlining code path This is refactoring work toward adding a new kind of .bzl loading context, for Bazel-internal .bzl files. Work toward #11437. Changes: - Add more documentation of the inlining behavior to save future readers some effort and make the invariants explicit. This also streamlines away some inline (haha) comments. - The recursive entry point to the inlining code path (computeInlineWithState()) now accepts InliningState, to keep the signatures more uniform and avoid forcing other callers to break encapsulation. Responsibility for registering child nodes with the parent is moved into that function. - Split cache-checking and child-registration logic (computeInlineWithState()) from code that runs only when we need to compute it from scratch (computeInlineForCacheMiss()). - Gave InliningState a little more responsibility: It now has a couple factory methods and manages the visited stack. A small change, but it helps readability. - Store a callback in InliningState instead of the whole cacheDataBuilder, to keep the knowledge minimal. (In the future, StarlarkBuiltinsFunction will grow an inlining code path that will call into computeInlineWithState(). The recordingEnv will be threaded through StarlarkBuiltinsFunction but unwrapped just before the call back to computeInlineWithState(), mirroring the current recursive call. I would've liked to avoid forcing callers to do this unwrapping and instead localizing the knowledge to computeInlineWithState(), but that would mean having computeInline() manufacture a dummy recordingEnv, which seemed confusing to readers.) RELNOTES: None PiperOrigin-RevId: 313665628
{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