Improve the specification and implementation of `NodeEntry#toValue`.

The only semantic change is that a `NonIncrementalInMemoryNodeEntry` that is rewound stores its previous value so that `toValue()` can return it while it is rewinding. This is consistent with how an `IncrementalInMemoryNodeEntry` already works, and since the implementation is now the same, `toValue()` is moved to the shared `AbstractInMemoryNodeEntry`.

The motivation for this is b/314117358: currently, `ArtifactNestedSetFunction` maintains a big map of built artifacts that is mostly redundant with data in the Skyframe graph. One exception is that currently artifacts in the big map are not evicted when their generating action is rewound, so a simultaneously executing action can still read them. Allowing `toValue()` to return a non-null value even for a rewound node makes it work consistently with how the big artifact map is currently used.

An alternative is to treat an unexpectedly-null value as a "lost input" under the assumption that it was rewound, and do more rewinding to recover from that. This may be more principled, however it is much more difficult to implement (we'd need to introduce the possibility of lost inputs before even attempting to executing the action) and is also inferior in the case of an action that generates multiple outputs: if only one output is lost, the entire action is rewound, although another output may still be available. In this case, the alternative approach could result in more rewinding than necessary.

Assertions for `toValue()` are peppered around various unit tests, and one new unit test case is added for the possibility of a node that is rewound and then reset.

PiperOrigin-RevId: 588122054
Change-Id: Ic3f4d7acff85fa626f13430658b7b832763955b1
9 files changed
tree: d4b12ccc1035a6db340fa33c3f7765d48adcfdd6
  1. .bazelci/
  2. .github/
  3. examples/
  4. scripts/
  5. site/
  6. src/
  7. third_party/
  8. tools/
  9. .bazelrc
  10. .bazelversion
  11. .gitattributes
  12. .gitignore
  13. AUTHORS
  14. bazel_downloader.cfg
  15. BUILD
  16. CHANGELOG.md
  17. CODE_OF_CONDUCT.md
  18. CODEOWNERS
  19. combine_distfiles.py
  20. combine_distfiles_to_tar.sh
  21. compile.sh
  22. CONTRIBUTING.md
  23. CONTRIBUTORS
  24. distdir.bzl
  25. extensions.bzl
  26. LICENSE
  27. maven_install.json
  28. MODULE.bazel
  29. MODULE.bazel.lock
  30. rbe_extension.bzl
  31. README.md
  32. repositories.bzl
  33. requirements.txt
  34. SECURITY.md
  35. WORKSPACE
  36. WORKSPACE.bzlmod
  37. workspace_deps.bzl
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