Baseline: 455454a5

Cherry picks:

   + 4caae75b:
     Automated rollback of commit
     8f956511.

Important changes:

  - The new path variable `$(rlocationpath ...)` and its plural form
    `$(rlocationpaths ...)` can be used to expand labels to the paths
    accepted by the `Rlocation` function of runfiles libraries. This
    is the preferred way to access data dependencies at runtime and
    works on all platforms, even when runfiles are not enabled (e.g.,
    on Windows by default).

This release contains contributions from many people at Google, as well as Ankush Goyal, Artem Zinnatullin, Christopher Peterson Sauer, Ed Schouten, Fabian Meumertzheim, Greg Magolan, keertk, Keith Smiley, nathyong, Robin Tweedie, Yannic Bonenberger, Yannic.

*** Reason for rollback ***

Breaks rules_kotlin android_test() targets.

*** Original change description ***

Allow Java coverage collection for external targets

PiperOrigin-RevId: 488453071
Change-Id: Ib63645058eb956271160c6c2cd205da90be39df6

Java targets depending on `@bazel_tools//tools/java/runfiles` can add the new `@AutoBazelRepository` to a class to have an annotation processor generate a companion class with a `BAZEL_REPOSITORY` constant containing the repository name of the target that compiled the class.

This requires a small addition to JavaBuilder to parse the repository name out of the target label and pass it to javac as a processor option.

Work towards #16124

Closes #16534.

PiperOrigin-RevId: 487573496
Change-Id: Id9b6526ce32268089c91c6d17363d1e7682f64a4

Fixed links & made other edits to release issue template

Closes #16697.

PiperOrigin-RevId: 487532320
Change-Id: I1a2901369aa2f96a858ea4b2b31189505bc6ac79

By adding the repository mapping manifest to runfiles as a root symlink, it is staged as `foo.runfiles/_repo_mapping` with all execution strategies. This includes sandboxed and remote execution, which previously did not stage the manifest at all.

As a side effect, runfiles libraries can now find the repository mapping manifest via `rlocation("_repo_mapping")`.

Fixes #16643
Work towards #16124

Closes #16652.

PiperOrigin-RevId: 487532254
Change-Id: I9774b8930337c5967fce92a861cc0db71dea2f0f

PiperOrigin-RevId: 487507720
Change-Id: I028dd6ca7b0d4fe5d843c94f6c0038935cf1007d

In the sentence **you will** was repeated twice consecutively.

Closes #16727.

PiperOrigin-RevId: 487493447
Change-Id: Id66f800e0fa197b55c6da2e4ae26220a0821ca74

Fixes : https://github.com/bazelbuild/bazel/issues/16723
PiperOrigin-RevId: 487493414
Change-Id: Id810ec50ca9d522a7c99b234bdaa9729582369bc

The root cause is some retriers in the test always retry the gRPC calls no matter what the exception is. Sometimes, the exception is CANCELLED due to the test case was interrupted by the framework since other tests failed. This is effectively sending the gRPC requests in an endless loop until test timed out.

PiperOrigin-RevId: 487491332
Change-Id: Iea3d345bf581c8a24678f45151cd80b77490d53a

Built at https://github.com/google/turbine/commit/5a314c52b8c700024469fec7e0506706d561908a



Partial commit for third_party/*, see #16725.

Signed-off-by: Sunil Gowroji <sgowroji@google.com>

--nouse_action_cache.

The method ExecutionTool#getActionCache, despite its name, may perform loading
an action cache if the actionCache is currently null. This caused the SKymeld
path to create an action cache instance despite the build having
--nouse_action_cache. This was caught by one of the integration tests.

This CL fixes that bug by having a separate method that just returns the
reference to the current in-use action cache instance, without attempting to
load it.

PiperOrigin-RevId: 487468119
Change-Id: I32a83236271cd96413f4ec54b8fa51f97ad1d828

IncrementalPackageRoots, which is retained by the ArtifactFactory, previously
held onto the EventBus instance after a build and prevented it from being
properly garbage collected. One of our integration tests caught this behavior.

This CL explicitly remove the reference upon calling #shutdown, so that
EventBus can be GC'ed.

PiperOrigin-RevId: 487467796
Change-Id: I96d1732c8efe23883d8e48839fd3db6ab01dd8b1

Like framework linkopts, they need to be handled specially to avoid the
-weak_framework flag being incorrectly deduped.  While we're at it, handle the
single word form of those args the same way for consistency, even though it's
not strictly necessary.

PiperOrigin-RevId: 487380019
Change-Id: I7e5c4d0c3bd34b582eaabccbe543ff6094439bf2

Remove `throws InterruptedException` from the signature of `PackageSerializerInterface#deserialize`.

An `InterruptedException` here is no longer possible in the actual implementations of this interface.

PiperOrigin-RevId: 487360589
Change-Id: I2db5e96b96b662b3bc138b9f6dd59130a8f6955a

The platform is part of the configuration, it cannot be modified by the configuration.

Fixes #16452 (by making it impossible).

Closes #16686.

PiperOrigin-RevId: 487271179
Change-Id: Ice61bcad368a3550515bbbf0989e26ef76098554

Also add argument comments to literals.

PiperOrigin-RevId: 487251986
Change-Id: I3fc14099f73047a7f73b5cc6440f9bba3438e6b6

I'm about to attempt this flag flip to see what breaks.

PiperOrigin-RevId: 487251570
Change-Id: Ia0e95ac4a1e04421cfdcd311c4500feef08c77d0

…n of flag --remote_download_{toplevel,minimal}.

So users don't need to add it manually.

It is always desired to use this flag along with BwoB.

Closes #13912.

Closes #16720.

PiperOrigin-RevId: 487248820
Change-Id: I94f6486a0a61522dc9000de7e9a595ace65c97e2

If the `category` field of the `@StarlarkBuiltin` annotation is not specified, it defaults to a "top-level module" category, which is often not correct. For example, in `attr.label(...)`, `attr` is a top-level module; but most of the things currently listed as top-level modules are not; instead, they should be listed as built-in types. This CL does just that.

PiperOrigin-RevId: 487211322
Change-Id: Ide6739e96e395b0bda6cd71b07e02590b0bb488c

PiperOrigin-RevId: 487206121
Change-Id: I0c4767e3d8ed6c4553fd8466d3f8f2e2270ccfa2

remote-apis PR 230 added a way where producers of Tree messages can    indicate that the directories contained within are stored in topological    order. The advantage of using such an ordering is that it permits    instantiation of such objects onto a local file system in a streaming    fashion. The same holds for lookups of individual paths.

Even though Bazel currently does not gain from this, this change at    least modifies Bazel's REv2 client to emit topologically sorted trees.    This makes it possible for tools such as Buildbarn's bb-browser to    process them more efficiently.

More details:
- https://github.com/bazelbuild/remote-apis/pull/229
- https://github.com/bazelbuild/remote-apis/pull/230

Closes #16463.

PiperOrigin-RevId: 487196375
Change-Id: Iafcfd617fc101fec7bfa943552113ce57ab8041b

PiperOrigin-RevId: 487193345
Change-Id: Id10c9aebad630928a9a33fa22824e4d78041a4d7

Always use `ToplevelArtifactsDownloader` when building without the bytes.

It checks the combination of current command (e.g. `build`, `run`, etc.) and download mode (e.g. `toplevel`, `minimal`) to decide whether download outputs for the toplevel targets or not.

Also in the `RunCommand`, we wait for the background downloads before checking the local filesystem.

Fixes #11920.

Closes #16545.

PiperOrigin-RevId: 487181884
Change-Id: I6b1a78a0d032d2cac8093eecf9c4d2e76f90380f

PiperOrigin-RevId: 487035019
Change-Id: I57220b0c733132e4bad624b2c8caab1e05ee5788

This adds a new parameter to the cc_common.compile API that is generally unsupported and should be removed in the future. The purpose of this change is to have a single API internally and in OSS.

RELNOTES:none
PiperOrigin-RevId: 487030674
Change-Id: I05c1b924257b3e6e653e21cdc5b28ec55aeec975

PiperOrigin-RevId: 486995274
Change-Id: I0be4ed1248e8e2dad6ff2dad4b1d36854c988aae

RELNOTES[inc]: java_import to require that the jars attribute be non-empty (#16385)

PiperOrigin-RevId: 486976650
Change-Id: If28c1ee0476d94a3359806ab04d61427a2d4da6b

fix: export constraints.bzl file from @local_config_platform so it can be used in downstream bzl_library targets

Downstream rule sets may depend on `@local_config_platform//:constraints.bzl` but when they do there is no way easy way to make that load statement compatible with `bzl_library`. This change makes it possible to use `bzl_library` on starlark code that loads from `@local_config_platform//:constraints.bzl`.

For example,

```
bzl_library(
    name = "local_config_platform_constraints",
    srcs = ["@local_config_platform//:constraints.bzl"],
)

bzl_library(
    name = "platform_utils",
    srcs = ["//lib/private:platform_utils.bzl"],
    deps = [":local_config_platform_constraints"],
)
```

Closes #16665.

PiperOrigin-RevId: 486957479
Change-Id: I328b7a3722aea95b3151ed88f23c277ed4154202

PiperOrigin-RevId: 486938898
Change-Id: I50af8fbdecc923d9a13af1d8ca6c61b0eeecf7c8

`-//foo` and `-@repo//foo` are always invalid Bazel options, but are usually meant to be either negative target patterns (which have to come after the `--` separator) or Starlark options (which always start with `--`).

With this commit, the error shown to the user mentions these two situations and how to fix the issue in each case.

Closes #16563.

PiperOrigin-RevId: 486920951
Change-Id: I9390d3859aa62c2b67eac05cb96a06209a9b7c36

So spawns can read content of directires within action exuection.

Part of https://github.com/bazelbuild/bazel/pull/16556.

PiperOrigin-RevId: 486918859
Change-Id: Ida86e4c927093d26f7f96d2f0c2aa0d1d74cc8a4

We typically omit "index" from URLs since both https://bazel.build/migrate/index and https://bazel.build/migrate point to the same index.md file.
However, the second URL breaks the "view source" button since it uses the path from the HTTP request, which lacks the essential "index" part.
Consequently, clicking the button led to a 404 error on GitHub.

This change fixes the problem by setting the correct source file path.

PiperOrigin-RevId: 486916394
Change-Id: I57c0ea58307f294ff52fe147aa21726c1c363f24

Only a subset of users may be allowed to update the action cache (e.g., only CI but not devs).

Today, there are 2 ways to achive the desired behavior:
  - `GetCapabilities` returning that all users are allowed to update, and `UpdateActionResult` returning an error that Bazel prints and ignores, or
  - have the users that are not allowed to update the action cache set `--remote_upload_local_results=false`.

Why don't we instead respect whether the remote cache supports uploading action results?

Note that this requires support from the remote system to fully work (i.e., it needs to return `update_enabled = false` for users that don't have permission). Otherwise, Bazel's behavior will be the same as before this change: failed `UpdateActionResult` do not cause the build to fail. The only change this introduces is that Bazel will no longer error if `--remote_upload_local_results=true` and `GetCapabilities` returning `update_enabled = false`.

Closes #16624.

PiperOrigin-RevId: 486901751
Change-Id: I0991f6891e21711df1e23ae0998a8bc95e2389bc

Debugging `disk_cache` at work, found this TODO in the code, decided to implement.

If `fsync` fails we don't rename to final name — which is the correct error handling as it was before if `copy` failed.

Closes #16691.

PiperOrigin-RevId: 486901488
Change-Id: Ia2aef6bc196e1d0a61f46b7b6c719563938ff48e

- This change is a follow-up to unknown commit which added the buttons to all narrative docs.
- It only affects the documentation generated from Java sources. Consequently, the docs at https://bazel.build/rules/lib/repo are currently out-of-scope (since they are generated by StarDoc).

Implementation details:
- `_buttons.html` received some logic that controls whether the "view source" button should be displayed, and which URL it points to. This decision depends on the newly added `source_file` variable.
- All relevant `.vm` template files now include `_buttons.html` and set the `source_file` variable.

As a result, there are now three scenarios:
1. Narrative documentation remains unchanged since it does NOT set the `source_file` variable. As a result, the "view source" button is displayed, with an URL pointing to the current Markdown page.
2. Reference documentation that is generated from multiple source files has `source_file="NONE"`, which means that no "view source" button will be displayed.
3. Reference documentation that is generated from a single file stores the path of said file in the variable. In this case the button will be displayed, too.

A notable example of scenario 3 are Starlark modules, since they all use `starlark-library.vm`. Consequently, I modified `StarlarkDocumentationCollector` and `StarlarkBuiltinDoc` to inject the correct value into the `source_file` variable.

PiperOrigin-RevId: 486896353
Change-Id: I600fa17f07914a4f489c65de0b04cfce8f20b9ec

A future change will add the buttons to the reference docs (which is a bit more complex since there is no 1:1 relation between displayed page and source file).

PiperOrigin-RevId: 486889786
Change-Id: I2d0d1963f7c82ab7b17dbe257196e4f105fe94cb

The previous setup (using TopLevelTargetAnalyzedEvent with an optionally filled
transitivePackagesForSymlinkPlanting) cause a subtle bug with the
BuildProgressPublisher with --discard_analysis_cache:

1. TopLevelTargetAnalyzedEvent(//foo, <pkgsForSymlinkPlanting>): status: //foo:
ANALYSIS -> TEST_FILTERING -> NOT_BUILT
...
2. TargetCompleteEvent(//foo): status: //foo: COMPLETE
3. Analysis cache discarded
4. TopLevelTargetAnalyzedEvent(//foo, []): status: //foo: COMPLETE -> ANALYSIS
(!!! Error !!!)

The 4th step happens because the de-duplication mechanism in
SkymeldBuildProgressPublisher failed to filter out the 2nd
TopLevelStatusAnalyzedEvent: it's not equal to the first one (the packages are
already discarded by step 3).

Having a separate TopLevelTargetReadyForSymlinkPlanting event would fix this
issue. From the perspective of BuildProgressPublisher, we don't care about
whether there's symlink planting or not.

PiperOrigin-RevId: 486880521
Change-Id: Icecbb67b7d938efb2741df52701ef7b0bd4bc2e0

The helper logic is only used in the BzlmodRepoRuleFunction so no need to have it in a separate place.
- Remove BzlmodRepoRuleHelper Interface & its implementations
- Refactor BzlmodRepoRuleFunction to use the helper logic
- Update tests and Build files accordingly

PiperOrigin-RevId: 486712547
Change-Id: I9a274a6a0afcc77be56bbe20e0c4d17c41c31c58

RELNOTES: None
PiperOrigin-RevId: 486669448
Change-Id: I8afea90dae33dad08d80e7fb0daf98aae081299b

Guidelines for Starlark rules suggest that `data`-like attributes on
rules should always merge the default outputs of rule targets into the
transitive runfiles. See:
https://docs.bazel.build/versions/main/skylark/rules.html#runfiles-features-to-avoid

As a result, Starlark rules generally don't (and shouldn't) explicitly
include their default outputs into their runfiles. Before this commit,
native rules did not merge these outputs in the same way as idiomatic
Starlark rules, which led to unexpectedly absent runfiles.

Fixes #15043

Closes #15052.

PiperOrigin-RevId: 486663801
Change-Id: I4a30b8b8a4dfc84bf4de27fd7894dd48e795c081