| commit | 6152425d599996573e1d0c5236198c689db68152 | [log] [tgz] |
|---|---|---|
| author | brandjon <brandjon@google.com> | Fri May 22 10:47:46 2020 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri May 22 10:49:04 2020 -0700 |
| tree | bbfe4c616db9686151eba50b74c2449911e1495b | |
| parent | bc884e14f16ab7d1f6729a0485dfc281239d16a5 [diff] |
Do .bzl load cycle detection by key instead of label The inlining code path for StarlarkImportLookupFunction does its own cycle detection since it doesn't use Skyframe. This CL changes it to look for cycles over the graph of bzl key dependencies, instead of their projection onto their labels. This allows two distinct keys that happen to have the same label to not spuriously trigger cycle detection when inlining. This is likely not a current problem in practice, because there doesn't seem to be a way to construct a non-cyclic path of load()s where any labels are repeated. Package bzl keys can't produce workspace keys and vice versa, even though the same .bzl file may be used for both. Likewise, I do not believe it's possible for the same label to be loaded in a cycle with distinct workspace chunking info, though I'm not 100% sure. When the new @builtins pseudo-repository is added, it may conflict with a proper external repo that happens to be named "@builtins", but even then the two shouldn't be able to load each other. All the same, let's cycle check the proper object in case any of these assumptions change in the future. It also brings the inlining case's cycle check in-line (ha-ha) with ordinary Skyframe evaluation's cycle check. This is refactoring work toward adding a new kind of .bzl loading context, for Bazel-internal .bzl files. Work toward #11437. RELNOTES: None PiperOrigin-RevId: 312842293
{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
