Tidy ConfiguredTargetFunction exception handling.

tl;dr: refactor messy code for clearer error messages

 - Clarify the difference between ConfiguredValueCreationException and DependencyEvaluationException:
 - ConfiguredValueCreationException: a failure of the target being evaluated. The current target is responsible for reporting the error to the user.
 - DependencyEvaluationException: a failure of one of its deps. The dep will report its own error so the current target only needs to report extra contextualizing information. Sometimes (unfortunately) this isn't possible, so this is togglable.
 - Include locations more consistently
 - Consolidate compute() catch logic
 - Consolidate error message reporting into a single place (in the compute() method) as much as possible
 - Clear error messages before sending them to ConfiguredTargetFunction. This
   prevents BuildTool from redundantly reporting those same messages.

This is only a partially successful attempt to clean up CTF's general error handling and reporting. The affected code has a lot of mutual dependencies that are hard to factor out. There's plenty more room for improvement. My hope is this at least improves on the status quo.

Followup ideas:

 - Try to reduce the number of Exception types. It's hard to keep track of them, adds a lot of code, and developers will inevitably use the wrong exception the wrong way
 - Better consolidate DependencyEvaluationException: it either represents a dep configured target that reported its own errors or it doesn't
 - Consolidate AspectFunction similarly to ConfiguredTargetFunction

Examples:

####################################
BEFORE (long error repeats twice):
####################################

ERROR: /myroot/errortest/BUILD:6:10: configurable attribute "srcs" in //errortest:cc doesn't match this configuration. Would a default condition help?

Conditions checked:
 //errortest:foo

To see a condition's definition, run: bazel query --output=build <condition label>.

This instance of //errortest:cc has configuration identifier 1fae62e. To inspect its configuration, run: bazel config 1fae62e.

For more help, see https://docs.bazel.build/configurable-attributes.html#why-doesnt-my-select-choose-what-i-expect.

ERROR: Analysis of target '//errortest:cc' failed; build aborted: configurable attribute "srcs" in //errortest:cc doesn't match this configuration. Would a default condition help?

Conditions checked:
 //errortest:foo

To see a condition's definition, run: bazel query --output=build <condition label>.

This instance of //errortest:cc has configuration identifier 1fae62e. To inspect its configuration, run: bazel config 1fae62e.

For more help, see https://docs.bazel.build/configurable-attributes.html#why-doesnt-my-select-choose-what-i-expect.

FAILED: Build did NOT complete successfully (41 packages loaded, 154 targets configured)

####################
AFTER:
####################

ERROR: /myroot/errortest/BUILD:6:10: configurable attribute "srcs" in //errortest:cc doesn't match this configuration. Would a default condition help?

Conditions checked:
 //errortest:foo

To see a condition's definition, run: bazel query --output=build <condition label>.

This instance of //errortest:cc has configuration identifier 5ece2f8. To inspect its configuration, run: bazel config 5ece2f8.

For more help, see https://docs.bazel.build/configurable-attributes.html#why-doesnt-my-select-choose-what-i-expect.

ERROR: Analysis of target '//errortest:cc' failed; build aborted:
FAILED: Build did NOT complete successfully (41 packages loaded, 154 targets configured)

####################################
BEFORE (redundant messaging):
####################################

ERROR: While resolving configuration keys for //testapp:g: no such target '//barr:c1': target 'c1' not declared in package 'barr' defined by /myroot/barr/BUILD
ERROR: Analysis of target '//testapp:g' failed; build aborted: no such target '//barr:c1': target 'c1' not declared in package 'barr' defined by /myroot/barr/BUILD

####################
AFTER:
####################
ERROR: /myroot/barr/BUILD: no such target '//barr:c1': target 'c1' not declared in package 'barr' defined by /myroot/barr/BUILD
ERROR: /myroot/testapp/BUILD:19:8: errors encountered resolving select() keys for //testapp:g
ERROR: Analysis of target '//testapp:g' failed; build aborted:
PiperOrigin-RevId: 383699655
8 files changed
tree: c98f1b7b99aac4250ba6183b694ffcad6462813b
  1. .bazelci/
  2. examples/
  3. scripts/
  4. site/
  5. src/
  6. third_party/
  7. tools/
  8. .bazelrc
  9. .gitattributes
  10. .gitignore
  11. AUTHORS
  12. BUILD
  13. CHANGELOG.md
  14. CODEBASE.md
  15. CODEOWNERS
  16. combine_distfiles.py
  17. combine_distfiles_to_tar.sh
  18. compile.sh
  19. CONTRIBUTING.md
  20. CONTRIBUTORS
  21. distdir.bzl
  22. distdir_deps.bzl
  23. ISSUE_TEMPLATE.md
  24. LICENSE
  25. README.md
  26. WORKSPACE
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Contributing to Bazel

See CONTRIBUTING.md

Build status