[7.2.0] Bzlmod lockfile exception about bazel

[brentleyjones]

Deleting the lockfile resolved it, until a new build where it fails again.

[brentleyjones]

MODULE.bazel.lock.txt

[Wyverald]

Dupe of #21845. We should fix it for 7.2.0.

Looks like you have a stray @zlib label somewhere in your MODULE.bazel, but are not use_repoing zlib.

[brentleyjones]

I use @zlib in the module extension that calls it in via http_archive, so I don't use_repo it. I added an unnecessary use_repo for it to work around the crash, but I shouldn't have to use_repo it since it's not used outside of the module extension.

This is the module extension:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@llvm-raw//utils/bazel:configure.bzl", "llvm_configure")
load("@llvm-raw//utils/bazel:terminfo.bzl", "llvm_terminfo_from_env")
load("@llvm-raw//utils/bazel:zlib.bzl", "llvm_zlib_from_env")

def _llvm_deps_impl(_):
    llvm_configure(name = "llvm-project")

    llvm_terminfo_from_env(
        name = "llvm_terminfo",
    )

    http_archive(
        name = "zlib",
        build_file = "@llvm-raw//utils/bazel/third_party_build:zlib.BUILD",
        sha256 = "91844808532e5ce316b3c010929493c0244f3d37593afd6de04f71821d5136d9",
        strip_prefix = "zlib-1.2.12",
        urls = [
            "https://storage.googleapis.com/mirror.tensorflow.org/zlib.net/zlib-1.2.12.tar.gz",
            "https://zlib.net/zlib-1.2.12.tar.gz",
        ],
    )

    llvm_zlib_from_env(
        name = "llvm_zlib",
        external_zlib = "@zlib",
    )

llvm_deps = module_extension(implementation = _llvm_deps_impl)

[Wyverald]

This here is the problem:

    llvm_zlib_from_env(
        name = "llvm_zlib",
        external_zlib = "@zlib",
    )

This @zlib label cannot be resolved because we don't know what @zlib is. You might say "it's declared right above!", but that's not how repo mappings in extension impl functions work (for better or for worse...). The repo mapping used here is always the mapping of the module hosting the extension (in this case, your root module), and the root module doesn't see a @zlib.

I realize this is very confusing, and am open to improving the situation. We could actually just add @zlib to the repo mapping after we declare @zlib -- that emulates WORKSPACE behavior to a certain degree -- which would also help address #19055, actually.