Bazel crashes with internal error when trying to concat dictionary with select on rules getting string_list_dict

[lior10r]

Description of the bug:

I wrote a custom rule which one of his attributes is of type string_list_dict.
I am concatenating dictionaries for simplicity, and some values I want to be dependent on a config, so I used a select and tried to concat the dictionaries with the select. When I try to do so it fails on an internal error:

Analyzing: target //check:test (1 packages loaded, 0 targets configured)
[0 / 1] [Prepa] BazelWorkspaceStatusAction stable-status.txt
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'ConfiguredTargetKey{label=//check:test, config=BuildConfigurationKey[ad2a6540989c55656a83c238ad8764286067c713283fa652a29a1eb44476b1c2]}' (requested by nodes 'ConfiguredTargetKey{label=//check:test, config=BuildConfigurationKey[d58942fd790f4054f5a9eb3fb575d5686af70045825a8c3693f82a04f134130f]}')
	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$RunnableExecuteAction.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: net.starlark.java.eval.Starlark$InvalidStarlarkValueException: invalid Starlark value: class java.util.ArrayList
	at net.starlark.java.eval.Starlark.checkValid(Starlark.java:135)
	at net.starlark.java.eval.Dict$Builder.put(Dict.java:495)
	at net.starlark.java.eval.Dict$Builder.putAll(Dict.java:504)
	at com.google.devtools.build.lib.packages.Type$DictType.concat(Type.java:616)
	at com.google.devtools.build.lib.packages.Type$DictType.concat(Type.java:518)
	at com.google.devtools.build.lib.packages.ConfiguredAttributeMapper.getResolvedAttribute(ConfiguredAttributeMapper.java:184)
	at com.google.devtools.build.lib.packages.ConfiguredAttributeMapper.getAndValidate(ConfiguredAttributeMapper.java:137)
	at com.google.devtools.build.lib.packages.ConfiguredAttributeMapper.validateAttributes(ConfiguredAttributeMapper.java:121)
	at com.google.devtools.build.lib.analysis.DependencyResolutionHelpers.visitRule(DependencyResolutionHelpers.java:254)
	at com.google.devtools.build.lib.analysis.DependencyResolutionHelpers.computeDependencyLabels(DependencyResolutionHelpers.java:118)
	at com.google.devtools.build.lib.skyframe.DependencyResolver.computeDependencies(DependencyResolver.java:697)
	at com.google.devtools.build.lib.skyframe.DependencyResolver.evaluate(DependencyResolver.java:388)
	at com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction.compute(ConfiguredTargetFunction.java:264)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:461)
	... 7 more

This didn't reproduce when the type of the attribute was string_dict

Which category does this issue belong to?

Configurability, Starlark Interpreter

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

I made a simple rule to reproduce. In a bzl file called try.bzl:

def _rule_impl(ctx):
    return DefaultInfo()

test = rule(
    implementation = _rule_impl,
    attrs = {
        "srcs": attr.string_list_dict(),
    },
)

and In the same directory in the BUILD file:

load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")
load(":try.bzl", "test")

bool_flag(
    name = "test_flag",
    build_setting_default = True,
)

config_setting(
    name = "setting_test",
    flag_values = {":test_flag": "true"}
)

test(
    name = "test",
    srcs = {"test1": ["123"]} | select({
        ":setting_test": {"test2": ["456"]},
        "//conditions:default": {},
    }),
)

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 7.0.2

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 ?

[email protected]:bazelbuild/bazel.git
e57d93f8d6326219fc2b1ffc75e22069c604e3c1

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

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

[iancha1992]

A fix for this issue has been included in Bazel 7.4.0 RC1. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.4.0rc1. Thanks!