Release Notes:

… clang-cl (#25467)

Addresses:
#24703 (comment)
PiperOrigin-RevId: 728571293
Change-Id: Ic1a292b6a6394e1c996cdaa1189e33431eb6f6d2

Commit
77137d4

Co-authored-by: Googler <pcloudy@google.com>

JDK 24 will be released in March, bazel 7.6.x should support it through
update of error-prone google/error-prone#4642

The earlier attempt in
e9a18ce
was not the correct fix, due to the requirements spelled out in the
utimensat(2) man page: if the current user has write permission but is
not the owner of the file, it may set both atime and mtime to UTIME_NOW,
but any other combination is forbidden. Although in theory we could
still leave the atime alone in other cases, it's not worth the
complexity: atime is often unreliable and Bazel doesn't care about it,
anyway.

Unfortunately, it's difficult to write an integration test for this,
because we can't arrange for the existence of multiple users in our CI
environment.

Fixes #23512.

PiperOrigin-RevId: 729042375
Change-Id: I7ca5e8bc0858a9796f448fca554d0c9465579e19

Commit
e7aef80

Co-authored-by: Googler <tjgq@google.com>

Valid empty `Tree` messages, which correspond to empty output
directories, serialize to two bytes since they always contain an empty
but present `Tree` message in the `root` field. Since such directories
are very common (for example, as undeclared test output directories), it
pays off to avoid downloading them.

Closes #25374.

PiperOrigin-RevId: 731614115
Change-Id: I64902afbecb55f718eb4d04fdd1f6207a7e8b97a 
(cherry picked from commit 6795c28)

…#25490)

The TLL governs the lifetime of the remote metadata, but shouldn't by
itself result in files being downloaded that otherwise wouldn't be
(e.g., with `--remote_download_minimal`). This fixes a bug that causes
warm Bazel servers with default settings apart from
`--remote_download_minimal` to start downloading all top-level artifacts
after three hours.

~This change also renames `shouldTrustArtifact` to `shouldTrustMetadata`
and updates some comments on `{Remote,}OutputChecker` to avoid confusion
between its two distinct purposes in the future: validating metadata and
deciding which artifacts to download.~ This part isn't cherry-picked.

Example of the effect:
buildbuddy-io/buildbuddy#8502 (comment)

Closes #25398.

PiperOrigin-RevId: 733280515
Change-Id: I35348a2a9b648ba0a563fb4f75b551349293754d 
(cherry picked from commit 23d03e1)

Closes #25490

C.UTF-8 is not available:
https://storage.googleapis.com/bazel-testing-buildkite-artifacts/01956bf0-7263-4136-89f2-4e2d785b8762/src/test/shell/integration/unicode_test/test_attempts/attempt_1.log

With this CL we'll set LC_ALL as we already do in other tests (e.g.
unicode_filenames_test.sh).

PiperOrigin-RevId: 734232499
Change-Id: I2a2c6ddbbfb4e9e7ac4c53dc80a9b0d28e007ab9

Commit
8dbfcfa

Co-authored-by: Googler <fwe@google.com>

This PR implements the "nodep" edges from
https://docs.google.com/document/d/1JsfbH9kdMe3dyOY-IR8SUakS541A7OM8pQcKpxTRMRs/edit?tab=t.0,
using the syntax of `bazel_dep(..., repo_name=None)`. The behavior is
that these edges are "unfulfilled" unless the module they refer to
already exist in the dep graph by some other means.

Most of the changes are in the Discovery class -- I reorganized the code
in there to hopefully help with readability, given the new multi-round
discovery logic.

Also changed `ModuleFileValue.Key` to no longer take the applicable
override next to the module key -- `ModuleFileFunction` now gets the
root module from Skyframe itself and looks up the correct override. The
old setup was always weird (what does it mean to request `foo@1.0` with
an incorrect override??).

Work towards #25214

RELNOTES: The `repo_name` parameter of `bazel_dep` can now be set to
`None` to mark it a "nodep" dependency -- that is, the `bazel_dep`
specification is only honored if the target module already exists in the
dependency graph by some other means.

PiperOrigin-RevId: 730962587
Change-Id: I1ca7a7a1228da5e4c2e4b5d6983a2ec97b31a4b8

---------

Co-authored-by: Yun Peng <pcloudy@google.com>

…ts (#25492)

*
3e115b9
*
e12fdd9

---------

Co-authored-by: Googler <jhorvitz@google.com>

Prior to this change, multiplex sandboxed workers shared a working
directory per mnemonic. This caused a race condition when a new
multiplex sandboxed worker with the same mnemonic was launched because
when launching it cleaned the working directory. That could cause
problems for any actions executing in that directory.

This change makes it so each multiplex sandbox worker process has a
unique working directory. It does so while ensuring each
SandboxedWorkerProxy and the associated sandbox are still associated
with the correct multiplexer process and working directory.

Resolves #22589

I couldn't figure out if the Bazel repo has an autoformatter somewhere,
so I did my best to manually format the code with a style that follows
the existing code.

Closes #25400.

PiperOrigin-RevId: 732256101
Change-Id: If8deea240fda77780feaeac352cf099fb9bfcee3 (cherry picked from
commit d54fc62)

Fixes #25460

Co-authored-by: jjudd <james@lab-y.com>