Beautify "no matching conditions" select() errors.
This is a common user problem: users see this error and don't understand what it
means or how to diagnose. This change is an opening salvo in a broader plan to
integrate more "beautiful" error messaging into Blaze, inspired by
https://bazel.build/designs/2016/05/23/beautiful-error-messages.html
Example:
config_setting(
name = "foo",
values = {"cpu": "not_a_valid_cpu},
)
config_setting(
name = "foo2",
values = {"cpu": "also_not_a_valid_cpu"},
)
cc_binary(
name = "cc",
srcs = select({
":foo": [],
":foo2": [],
}))
$ blaze build //testapp:cc
Before:
-----------
ERROR: /workspace/testapp/BUILD:16:10: Configurable attribute "srcs" doesn't match this configuration (would a default condition help?).
Conditions checked:
//testapp:foo
//testapp:foo2
After:
-----------
ERROR: /workspace/BUILD:16:10: configurable attribute "srcs" in //testapp:cc doesn't match this configuration. Would a default condition help?
Conditions checked:
//testapp:foo
//testapp:foo2
//testapp:foo3
To see a condition's definition, run: bazel query --output=build <condition label>.
This instance of //testapp:cc has configuration identifier 7f2b080. To inspect its configuration, run: bazel config 7f2b080.
For more help, see https://docs.bazel.build/configurable-attributes.html#why-doesnt-my-select-choose-what-i-expect.
Themes:
-----------
- This is consciously longer and more verbose. The primary goal is *clarity*,
which is not always aligned with shortness. This includes paragraph-style
line spacing to de-densify potentially overwhelming content.
- Uses casual but personable language, including actionable phrasing ("see", "run")
to help guide understanding and diagnostics.
- Provides a thorough walkthrough including proposed next steps for the
immediate problem while leaving discussion on broader concepts to outside
links.
- Increases our commitment to "always supported URLs" (including in-page
anchors!)
- Main idea is to look like the cleanest, most helpful Stackoverflow-style answer
possible. There's no intrinsic reason why internal messaging can't be held
to the same accessibility standards.
For https://github.com/bazelbuild/bazel/issues/11984.
PiperOrigin-RevId: 369470807
diff --git a/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java b/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java
index 36d84d2..d8c163c 100644
--- a/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java
+++ b/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java
@@ -1915,7 +1915,8 @@
Preconditions.checkNotNull(visibility);
Preconditions.checkNotNull(constraintSemantics);
AttributeMap attributes =
- ConfiguredAttributeMapper.of(target.getAssociatedRule(), configConditions.asProviders());
+ ConfiguredAttributeMapper.of(
+ target.getAssociatedRule(), configConditions.asProviders(), configuration.checksum());
checkAttributesNonEmpty(attributes);
ListMultimap<String, ConfiguredTargetAndData> targetMap = createTargetMap();
// This conditionally checks visibility on config_setting rules based on
@@ -2128,8 +2129,9 @@
ctMap.put(
AliasProvider.getDependencyLabel(prerequisite.getConfiguredTarget()), prerequisite);
}
- List<FilesetEntry> entries = ConfiguredAttributeMapper.of(rule, configConditions)
- .get(attributeName, BuildType.FILESET_ENTRY_LIST);
+ List<FilesetEntry> entries =
+ ConfiguredAttributeMapper.of(rule, configConditions, configuration.checksum())
+ .get(attributeName, BuildType.FILESET_ENTRY_LIST);
for (FilesetEntry entry : entries) {
if (entry.getFiles() == null) {
Label label = entry.getSrcLabel();
