Clear potentially stale state left in `CppCompileAction` from inputs discovery from a previous build.

`CppCompileAction` [stores intermediate state](https://github.com/bazelbuild/bazel/blob/b341802700484d11c775bf02d80f43ba3f33b218/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java#L524) of inputs discovery in the action
itself to avoid quadratic reevaluation on missing Skyframe dependencies. The
state is later [cleared when the execution of the action starts](https://github.com/bazelbuild/bazel/blob/b341802700484d11c775bf02d80f43ba3f33b218/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java#L1425). This
is principally a problematic approach since we are mutating an analysis time
object (action) during execution.

In particular, if we happen to start discovering inputs, but not execute the compile spawn, the state will be left in the action object. A later build, at a different version, would pick up the stale state and use it as discovered inputs leading to incorrect results (or failures) for such incremental build.

This is possible e.g. when running a build without `--keep_going` when a failure from another action interrupts the execution after inputs discovery or when the `ActionExecutionFunction` encountered a missing dependency in the middle of discovering inputs (e.g. it did not have [dependent modules available](https://github.com/bazelbuild/bazel/blob/b341802700484d11c775bf02d80f43ba3f33b218/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java#L549-L551)).

Add a new method to call before the first invocation of `Action::discoverInputs` in each build. Add a boolean flag to detect the first call to `Action::discoverInputs` stored in the Skyframe state used by `ActionExecutionFunction` and use it to clear the potentially stale state.

PiperOrigin-RevId: 420386548
4 files changed
tree: 2196dc18cd3ed1c4aff771c18efd3b28120bdcaf
  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. CODE_OF_CONDUCT.md
  15. CODEBASE.md
  16. CODEOWNERS
  17. combine_distfiles.py
  18. combine_distfiles_to_tar.sh
  19. compile.sh
  20. CONTRIBUTING.md
  21. CONTRIBUTORS
  22. distdir.bzl
  23. distdir_deps.bzl
  24. ISSUE_TEMPLATE.md
  25. LICENSE
  26. MODULE.bazel
  27. README.md
  28. SECURITY.md
  29. WORKSPACE
  30. WORKSPACE.bzlmod
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

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status