Embed builtins bzls as a Java resource
Currently the builtins .bzl files are packaged into, and read from, the install base. However, there is no install base in our Java unit tests, as well as in BazelPackageLoader. To support these use cases, we now instead embed the builtins_bzl.zip as a Java resource, and extract it to a fresh InMemoryFileSystem upon ConfiguredRuleClassProvider construction. The flag value --experimental_builtins_bzl_path=%install_base% has been renamed to "%bundled%".
A previous prototype attempted to make ServerDirectories responsible for knowing how to access the bundled bzls. This was problematic because it required updating all instantiators of ServerDirectories (mostly tests), and complicated the target graph. The new design puts this knowledge in BazelRuleClassProvider, alongside the other rule logic registration. This avoids an undesirable situation whereby any un-updated test could block proper use of builtins injection in production.
The only loss of not having builtins bzls live in the install base is that their sources are not immediately available to a debugger; you have to use --experimental_builtins_bzl_path=<some staging location> instead. This matches the intended workflow when developing builtins bzl code anyway.
Our typical way of locating resource files (ResourceFileLoader) is to resolve them relative to a given Java class. But the builtins zip does not live underneath the java tree. If we tried to add it directly as a resource, then the java_binary rule would create the jar entry under its absolute package path instead of its relative path within the java root. So instead we use a genrule to copy it into the java tree where needed.
Misc:
- Expose a method in ResourceFileLoader to compute a resource path without retrieving it yet. This avoids the inconvenience of having to pass two args (a Class and a relative resource name) around.
- Drive-by removal of a bunch of BUILD deps made obsolete by a recent configuration machinery cleanup. Likewise, drive-by auto-formatting of some files affected by the prior version of this CL.
- Added the builtins zip to the distfile, for bootstrapping. This didn't belong in either the "srcs" tree or the "derived_java_srcs" target, so I added it directly as a distfile dep.
- Fixed a hashCode/equals bug in ServerDirectories.
Work toward #11437.
PiperOrigin-RevId: 347697763
diff --git a/src/main/java/com/google/devtools/build/lib/analysis/BUILD b/src/main/java/com/google/devtools/build/lib/analysis/BUILD
index 37091e9..d468ebd0a8 100644
--- a/src/main/java/com/google/devtools/build/lib/analysis/BUILD
+++ b/src/main/java/com/google/devtools/build/lib/analysis/BUILD
@@ -434,6 +434,7 @@
"//src/main/java/com/google/devtools/build/lib/util/io:out-err",
"//src/main/java/com/google/devtools/build/lib/vfs",
"//src/main/java/com/google/devtools/build/lib/vfs:pathfragment",
+ "//src/main/java/com/google/devtools/build/lib/vfs/inmemoryfs",
"//src/main/java/com/google/devtools/build/skyframe",
"//src/main/java/com/google/devtools/build/skyframe:skyframe-objects",
"//src/main/java/com/google/devtools/common/options",
