[7.2.0] Bzlmod lockfile exception

[brentleyjones]

Description of the bug:

Computing main repo mapping: 
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue$$Lambda/0x00000008002c2bb8@75a79aa0' (requested by nodes 'RegistryKey{url=https://bcr.bazel.build/}')
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:550)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:414)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: com.google.devtools.build.lib.cmdline.LabelSyntaxException: invalid repository name '[unknown repo 'zlib' requested from @@]': repo names may contain only A-Z, a-z, 0-9, '-', '_', '.' and '~' and must not start with '~'
        at com.google.devtools.build.lib.cmdline.Label.parseCanonicalUnchecked(Label.java:155)
        at com.google.devtools.build.lib.bazel.bzlmod.AttributeValuesAdapter.deserializeStringToObject(AttributeValuesAdapter.java:175)
        at com.google.devtools.build.lib.bazel.bzlmod.AttributeValuesAdapter.deserializeObject(AttributeValuesAdapter.java:114)
        at com.google.devtools.build.lib.bazel.bzlmod.AttributeValuesAdapter.read(AttributeValuesAdapter.java:63)
        at com.google.devtools.build.lib.bazel.bzlmod.AttributeValuesAdapter.read(AttributeValuesAdapter.java:44)
        at com.google.devtools.build.lib.bazel.bzlmod.RepoSpec_GsonTypeAdapter.read(RepoSpec_GsonTypeAdapter.java:105)
        at com.google.devtools.build.lib.bazel.bzlmod.RepoSpec_GsonTypeAdapter.read(RepoSpec_GsonTypeAdapter.java:11)
        at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
        at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
        at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:195)
        at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:17)
        at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
        at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
        at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
        at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
        at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
        at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:129)
        at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:15)
        at com.google.gson.Gson.fromJson(Gson.java:991)
        at com.google.gson.Gson.fromJson(Gson.java:956)
        at com.google.gson.Gson.fromJson(Gson.java:905)
        at com.google.gson.Gson.fromJson(Gson.java:876)
        at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.getLockfileValue(BazelLockFileFunction.java:93)
        at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.compute(BazelLockFileFunction.java:73)
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:461)
        ... 7 more
Caused by: com.google.devtools.build.lib.cmdline.LabelSyntaxException: invalid repository name '[unknown repo 'zlib' requested from @@]': repo names may contain only A-Z, a-z, 0-9, '-', '_', '.' and '~' and must not start with '~'
        at com.google.devtools.build.lib.cmdline.LabelParser.syntaxErrorf(LabelParser.java:208)
        at com.google.devtools.build.lib.cmdline.RepositoryName.validate(RepositoryName.java:160)
        at com.google.devtools.build.lib.cmdline.LabelParser$Parts.validateRepoName(LabelParser.java:180)
        at com.google.devtools.build.lib.cmdline.LabelParser$Parts.validateAndCreate(LabelParser.java:72)
        at com.google.devtools.build.lib.cmdline.LabelParser$Parts.parse(LabelParser.java:164)
        at com.google.devtools.build.lib.cmdline.Label.parseCanonical(Label.java:141)
        at com.google.devtools.build.lib.cmdline.Label.parseCanonicalUnchecked(Label.java:153)
        ... 36 more

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

macOS 14.5.0

What is the output of bazel info release?

release 7.2.0rc1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[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.