Backports https://github.com/bazelbuild/rules_java/commit/b3a0580e0a9a6b8b28b611c7dd6164c06b279539

Fixes https://github.com/bazelbuild/bazel/issues/25648

Numeric segments can now be unsigned longs rather than just signed
integers. Segments that exceed this (large) range now result in an error
rather than a crash.

Work towards #23461

Closes #24945.

PiperOrigin-RevId: 718451995
Change-Id: I141b707e8c28d5fe764b47b4c35f163a3621e4c5

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Built at commit ee12906c

Relevant changes:

* Add support for input FN lines that include a function end line
(#25118).

RELNOTES:
LCOV parsing does not break on FN lines including an end line number.

Closes #25200.

PiperOrigin-RevId: 723451534
Change-Id: I8912082ae6517bf0359329004d9a4f5e9ac76188

Commit
https://github.com/bazelbuild/bazel/commit/df92905c72607ea369458e4a6af43bb785670528



---------

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

Check that the actual coverage data simply contains the expected
coverage data, rather than checking for an exact match. This matters for
when we start to process baseline coverage, which may result in header
files getting included in the report. This is in-keeping with the other
coverage tests.

Also adds the branch data into the reports, which we will check when
we're using an LLVM version that supports branch coverage, and a test
that checks header files that include coverage data are actually
included in the final report.

Required for https://github.com/bazelbuild/bazel/pull/24593

Closes #24624.

PiperOrigin-RevId: 705177531
Change-Id: I2247434d0b005f2218761249238e52597a452e12

Commit: 164c4821

This should have been a part of
https://github.com/bazelbuild/bazel/pull/23525, but was inexplicably
missing when it was cherry-picked from 8c5e9dab.

Valid repository names are a strict superset of valid Starlark
identifiers, but need to be specified as keyword arguments for
`MODULE.bazel` functions such as `override_repo` and `use_repo`. This is
made possible by relaxing the syntax checker for `MODULE.bazel` files
only, which now allows
```
override_repo(ext2, **{"foo.2": "foo"})
```
but not
```
KWARGS = {"foo.2": "foo"}
override_repo(ext2, **KWARGS)
```

Fixes #19635
Fixes #25551

Closes #25553.

PiperOrigin-RevId: 737928093
Change-Id: Iff5d740ef2101973e6d3da95edf73befd21afab7
(cherry picked from commit 1f541440)

Fixes #25614

…ed but not executed.

This would previously show confusing metrics such as
```
  {
    "mnemonic": "FileWrite",
    "firstStartedMs": "10965232776311",
    "lastEndedMs": "1741860739457",
    "actionsCreated": "10"
  },
```

PiperOrigin-RevId: 737613747
Change-Id: I544f220766c4170318c7f1438584c5613fdc8fa0

Commit
https://github.com/bazelbuild/bazel/commit/bcfd3e7be9e0414ecb11f0d0d9d9a55d3d276fd6



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

This test is mysteriously failing on mac, and only _sometimes_. Given
that WORKSPACE is going away and this is testing an experimental flag
anyway, we should just delete this test.

[7.6.0] Use runfiles path instead of root relative path in `JavaStarlarkCommon.collectNativeLibsDirs` (#25548)

Fixes https://github.com/bazelbuild/bazel/issues/25012

Closes #25043.

PiperOrigin-RevId: 719211390
Change-Id: I91267b3ce546a54cd065e4424f3e80aaa36cff28

Commit
https://github.com/bazelbuild/bazel/commit/8fba20855f7979ecc61cb05bf9e3ec8890aeed90



---------

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

The previous attempt accidentally upgraded to 2.26.0 instead.

Bazel 7 emits the `BAZEL_CURRENT_REPOSITORY` preprocessor macro only
when depending on the copy of the cc runfiles library in `@bazel_tools`,
breaking users who want to write forwards-compatible code which pulls
that
library from `@rules_cc`.  In commit 6f7faa65, a backport of 8a5e70c7,
Bazel 8.1 replaced its own implementation with a passthrough and updated
the check that macro uses to permit both locations.

This patch gives rules_cc users forwards-compatibility by backporting
the portion of that commit which emits the `BAZEL_CURRENT_REPOSITORY`
variable when using the runfiles library from rules_cc, but stops short
of actually removing the built-in runfiles library.

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 d54fc621

)

Fixes #25460

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

*
https://github.com/bazelbuild/bazel/commit/3e115b937d7f6eff5c819667c6f6226c8fdba466
*
https://github.com/bazelbuild/bazel/commit/e12fdd93a3e22163d37209634ad5546f9fccd3bf



---------

Co-authored-by: Googler <jhorvitz@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 https://github.com/bazelbuild/bazel/issues/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>

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
https://github.com/bazelbuild/bazel/commit/8dbfcfae924b014366a0b47cd26632c5076b51a2



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

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:
https://github.com/buildbuddy-io/buildbuddy/pull/8502#issuecomment-2687734121

Closes #25398.

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

Closes #25490

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 6795c28a)

The earlier attempt in
https://github.com/bazelbuild/bazel/commit/e9a18ce24b176f0d9a46af341ed44895c06b7214
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 https://github.com/bazelbuild/bazel/issues/23512.

PiperOrigin-RevId: 729042375
Change-Id: I7ca5e8bc0858a9796f448fca554d0c9465579e19

Commit
https://github.com/bazelbuild/bazel/commit/e7aef800b313061f982da6ad392de88d5712f9f0



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

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

Addresses:
https://github.com/bazelbuild/bazel/pull/24703#issuecomment-2665963637
PiperOrigin-RevId: 728571293
Change-Id: Ic1a292b6a6394e1c996cdaa1189e33431eb6f6d2

Commit
https://github.com/bazelbuild/bazel/commit/77137d42d1958b7ca68fe1a3ed7644cde1b7328c



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

Release Notes:

The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes #25063

Closes #25067.

PiperOrigin-RevId: 720592796
Change-Id: Ia202ca4a8482a81da8085ee18ecaca5fe233bddb

---------

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Previously, we only supported attribute types which could be defined for
Starlark rules, with the result that a cherry-pick in the 7.x branch
exposing a formerly native-only attribute type to Starlark broke
Stardoc: https://github.com/bazelbuild/stardoc/issues/277

Instead of picking and choosing, let's support all attribute types, same
as we already do in Bazel 8 and newer.

Cherry-pick of a subset of changes in commit

https://github.com/bazelbuild/bazel/commit/1ce4ab15fab18063d8291132ea84e71fa02d27c4

PiperOrigin-RevId: 675169119
Change-Id: I6541a5eb99d6257339032850d360d2da4bd5aeb4

ea4ad30d added an action as context for
prefetches with BwoB, but assumed that all callers would use the
prefetcher for inputs to locally executed actions. However, since then,
it has also been used to download outputs of completed actions that have
been explicitly requested (e.g. as outputs of top-level targets or those
matching the regex path patterns). This resulted in downloads with a
`prefetcher` action ID and action details for the action that produced
the file, rather than consumed it, resulting in confusing situations for
observability tools.

This is fixed by separately tracking the reason for the fetch. Using an
action ID of `output` when the action has the requested file as an
output, and "input" when the action has the requested file as an input.

Closes #25040.

PiperOrigin-RevId: 719246746
Change-Id: Ib95ff65ba68112b1a38ab3022e5b1a19ef74cc9f 
(cherry picked from commit 998e7624)

RELNOTES: CAS requests made when Bazel downloads a blob with Build
without the Bytes enabled now provide metadata with an action ID of
`input` if the blob is downloaded as the input to a local action and
`output` if it is a requested action output.

[7.5.0] Update relnotes script to follow the patch release format for minor releases with no RELNOTES tags (#25025)

PiperOrigin-RevId: 718504556
Change-Id: I54f42e07721935c44a6f2a314b59864d6433d865

Commit
https://github.com/bazelbuild/bazel/commit/c38bed0592ad2a2a5a8402dc0fb625ea63c6643d



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

This option, which is different from the startup option of the same
name, has no effect and doesn't even show a warning, which can be
confusing.

Closes #24953.

PiperOrigin-RevId: 717853503
Change-Id: I8d7d1229f692007c4350b6c15526b7a95bbed5ef

Commit
https://github.com/bazelbuild/bazel/commit/79508becbb9195dc59e24b9aa3dbaf880c209e2e



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

... if the corresponding output is materialized afterwards and hasn't
been changed.

Failing to do so will cause an incremental build to re-check the action
cache for actions whose outputs were materialized during last build.
This can be very slow if the size of the outputs are large.

We achieved this by storing `FileContentsProxy` in the remote metadata
after materialization. During dirtiness check, we compare remote
metadata and the corresponding local metadata with their `digest`, or
`proxy` if `digest` is not available for local metadata,

A user reported back the wall time of their very first increment build
is improved by this change from `14s` to less than `1s` in common case,
and from `115s` to less than `1s` in worst case.
https://github.com/bazelbuild/bazel/issues/24763

PiperOrigin-RevId: 715734718
Change-Id: Id1a1a59d8b5f3e91a7ae05a73663ff37eee6d163

Fixes #24920.

PiperOrigin-RevId: 715819891
Change-Id: I1c2e582a3d4c6e87e5c76837abb7a175eed3e850 
(cherry picked from commit c570f978

)

Fixes #24933

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

This makes it possible to retroactively link an execution log file to a
particular build.

Closes #24790.

PiperOrigin-RevId: 715017597
Change-Id: Ia8f6a3677a165a9f428b59ab8a19587a357b8803

Commit
https://github.com/bazelbuild/bazel/commit/fd6a9833ba9fe18799193295b82134bc64ab17b3



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Fixes #24770

Closes #24887.

PiperOrigin-RevId: 714107497
Change-Id: Ib914aa54b2afa2a90fcce2f2263b9c1b2d2c193c

Commit
https://github.com/bazelbuild/bazel/commit/6a141eab3fa5d57eb8b5dadbb6260a120c597fe9



Co-authored-by: Dave Roth <davidroth@google.com>

Fixes #24882

Closes #24883.

PiperOrigin-RevId: 714854122
Change-Id: I5e48e84f88606320223a9969e8367924aeeb13dd

Commit
https://github.com/bazelbuild/bazel/commit/6423b04c1bf95bc0e9ef99667688b3763c3bce4e



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

The jar can be supplied separately as it needs to be passed to the
`-javaagent` JVM arg anyway.

Also update the recommended version for compatibility with Java 21.

Fixes #24782

Closes #24783.

PiperOrigin-RevId: 714057306
Change-Id: Ic8d47562f15344ed16d0af5d3242937d2ee53b22

(cherry picked from commit b59fbeee)

Fixes #24788

This makes it easier for users to discover that a module hasn't been
found because its absence was recorded in the lockfile during a previous
build.

Fixes #24803

Closes #24804.

PiperOrigin-RevId: 713142592
Change-Id: Id541f5710481bd947c09d8dba315d683a1666b1c 
(cherry picked from commit 6061e5ea)

Fixes #24805

Fixes #24730

Closes #24735.

PiperOrigin-RevId: 713606521
Change-Id: If8578fcdfc30dcbfb6af283089614f3364eb30d8

Commit
https://github.com/bazelbuild/bazel/commit/e78bab504940ea2abce749cf8654320cc2fbf96f



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

This protects against an integer overflow which could occur for large
key list size and large thread counts.

Regrettably, it's difficult to write a regression test for this
scenario, as exercising this overflow requires lots of time and heap, so
it would be a performance regression to our test suites.

Fixes https://github.com/bazelbuild/bazel/issues/19445

PiperOrigin-RevId: 595420516
Change-Id: Ic0a475a6a273c50fe9895dd0852fa5b062859cb2

Commit
https://github.com/bazelbuild/bazel/commit/3e373d0abc79e40b3fa46aca4aa268c5ae9b7dc2



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

This allows IDEs to query for the direct dependencies of the root module
as well as how they can refer to them from the point of view of the root
module.

Also always emit `name` and `version` so that consumers don't have to
know how to parse module keys.

Work towards #22691

Closes #23787.

PiperOrigin-RevId: 693453084
Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a (cherry picked from
commit 1003d2c3)

Fixes #24678

The warnings tell the user to run `bazel mod tidy`, which is very
confusing.

Fixes #24495

Closes #24729.

PiperOrigin-RevId: 708007222
Change-Id: I60dc889281a776bbf08a7f9537272d7692cce1d8 
(cherry picked from commit 455ddb74)

Fixes #24740

Fixes https://github.com/bazelbuild/bazel/issues/23247

Closes https://github.com/bazelbuild/bazel/issues/24768

PiperOrigin-RevId: 707176116
Change-Id: I71ef3c630f8130467cc6a0c730c1278ae6b0817f
(cherry picked from commit 03eae37f)

…thout the checksum

This PR address the #23932 issue with remote downloader.

Closes #23970.

PiperOrigin-RevId: 686180819
Change-Id: Ia36c5793622bd1ac1fdaa9ef1326ddc385a5a01f

(cherry picked from commit 60638af7

)

Fixes #24837

Co-authored-by: Mislav Mandaric <mislav.mandaric@happening.xyz>

auto does not exist in Bazel 4, 5, 6 or 7. I'm not sure if was there
before but in any of these versions when trying it the following error
appears

ERROR: While parsing option --dynamic_mode=auto: Not a valid dynamic
mode: 'auto' (should be off, default or fully)

Fixes: https://github.com/bazelbuild/bazel/issues/20707

Closes #20705.

PiperOrigin-RevId: 630063050
Change-Id: Ib0b0427268a885d6ffc62c81183b6dd24a6dc517 (cherry picked from
commit a70a28f2)