When preparing an action for rewinding, evict it from the action cache to ensure that it is executed.

PiperOrigin-RevId: 574158458
Change-Id: I82075f9a1a79cdd601ac6e0d2b3c17969dae81ca

Fixes #16285.

RELNOTES: Enable Platforms and Toolchains for Android. Android projects will need to stop passing the legacy flag `--fat_apk_cpu`, and instead use `--android_platforms` using platforms defined with the `@platforms//os:android` constraint. The https://github.com/bazelbuild/rules_android repository defines four standard Android platforms for projects that use those rules, `@rules_android//:armeabi-v7a`, `@rules_android//:arm64-v8a`, `@rules_android//:x86`, `@rules_android//:x86_64`.

Blog post describing these changes to follow.

Closes #19726.

PiperOrigin-RevId: 574153852
Change-Id: Ief1e1be95fa03dd038a912dd318628ffdd562eaa

This follows the design document, allowing only extending aspects list and the default value.

It would be less complex to implement `attr.override(aspects = ...)` and it could potentially solve problem of mixing new and overridden attributes.

PiperOrigin-RevId: 574139579
Change-Id: I3261aacd9929a5d25039ba36301d20e8cefcd0bf

Set computed default to deps only when we need to propagate graph_node aspect.

This change makes it possible to collapse cc_binary and cc_test into a single rule.

PiperOrigin-RevId: 574139119
Change-Id: I58f54c87487387cf63658cde96f61a03a5e49876

This was already the case in another place of the same file, but not all.

Failing to do so causes Bazel missing the action cache for CppCompileAction with sibling layout.

Fixes #17819.

PiperOrigin-RevId: 574134623
Change-Id: I602fc988ea6d066c394b2638c3084e5add08353d

Ensure that `BazelLockFileModule` only updates `MODULE.bazel.lock` if the content of the file needs to change. Every such update changes the file's metadata, which results in Skyframe invalidation of, in particular, all configurations. This broke `bazel config`, which uses `MemoizingEvaluator#getDoneValues()` to directly observe Skyframe state.

Since this type of invalidation can also be caused by users and deviates from the usual "incremental correctness" guarantees provided by Bazel, let `config` show a descriptive error when no configurations are found.

Fixes #19823

Closes #19842.

PiperOrigin-RevId: 574133346
Change-Id: I5886c91fc6b7b938a7dee59ea75aa7b8afb5b161

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

PiperOrigin-RevId: 574130268
Change-Id: Id4813b8a61edb2a25d223f0bb5727cf31b7ccc11

This was an oversight in https://github.com/bazelbuild/bazel/commit/5100d8716f4b9ce25db40c131a94f346055ca9cb. We're also not handling source directories correctly, but given their frowned-upon status, let's ignore it for now.

I have a larger CL to make it impossible to misuse the LocalFile constructor (by passing in the Artifact and deriving the type from it), but it snowballed into a fairly large refactor, so I'd rather do it after Bazel 7 is cut.

Fixes #19151.

PiperOrigin-RevId: 574128307
Change-Id: Ib07150c6b900b1b99e683c8ce7b6cafe6da1500e

Rename ActionMetadataHandler to ActionOutputMetadataStore and ActionInputMetadataStore to ActionInputMetadataProvider.

There are still bits and pieces that refer to "MetadataHandler" in some form in our test cases, but that's not a mechanical rename and it's fiddly so I'd rather do it separately (if ever)

RELNOTES: None.
PiperOrigin-RevId: 574113235
Change-Id: I86877e53866ad74ade24e419bfc10328c13f9a35

Partial roll forward of https://github.com/bazelbuild/bazel/commit/5ac62a2a5bfc04387d904f6ff1e74c6290bda9fd.

Keep build_info api in cc_common, once android rules are released delete it.

*** Original change description ***

BEGIN_PUBLIC

Switch Cpp `BuildInfo` system to new API.

END_PUBLIC

PiperOrigin-RevId: 574112862
Change-Id: I7cdc2a93499f3681bec9b5b03d0e11f84099cfa0

This type is currently only used at Google.

Work towards enforcing the invariant that the OUTPUT, OUTPUT_FILE, OUTPUT_DIRECTORY and OUTPUT_SYMLINK types are used iff the output has an associated Artifact.

PiperOrigin-RevId: 574112783
Change-Id: I8257f021784b604bd10cb202f6f0d4ccd8e161b1

They are referred to within the repository, but since they are not defined the references fail and cause query failures.

Closes #19835.

PiperOrigin-RevId: 574109198
Change-Id: I892745101ffc63e3b59eae656996016a213bd121

Since the plan is to enable automatic-exec-groups globally (and is anyways enabled for all the rules that will use subrules to begin with), instead of introducing more parallel code paths, I think it makes sense to restrict toolchain usage in subrules to requiring automatic-exec-groups.

PiperOrigin-RevId: 574096795
Change-Id: I331d46666be8f9e085051d43c387e78b5fa56d64

Hopefully resolve timeout failure of this test recently, for example https://buildkite.com/bazel/bazel-bazel/builds/25260

RELNOTES:None
PiperOrigin-RevId: 574068852
Change-Id: Icfc6c3b1070634c379caa0ae333a769a1f2d1f55

If the select() resolves to an empty list we will not include the proguard map
in the dexing provider, so need to conditionally pull it from the optimization
info provider.

PiperOrigin-RevId: 574041946
Change-Id: Iff49d382abea4674e79938698b022079537fd633

Also adds a repeated `Any` field for strategies to report strategy-specific
execution details.

First commit addressing issue #19471.

PiperOrigin-RevId: 573896902
Change-Id: I3d58cdfb503d552999c6261fc7fbd04c7d1de835

The final javacopts passed to `JavaBuilder`/`javac` is computed (in `java_common.compile`) by concatenating the following sets of options (in order):

1. The `javacopts` attribute on `java_toolchain`
2. The options provided with `--javacopt` on the commandline
3. The matching `compatible_javacopts` attribute on `java_toolchain`
4. The matching options from `java_toolchain.package_config`
5. The `javacopts` attribute on the `java_*` rule

We already de-tokenize each of these sets into a single space-separated string before adding them to a `depset` (not doing so would mean `['-source', '8', '-target', '8', '-Xmx1G']` would result in getting back `['-source', '8', '-target', '-Xmx1G']` from the depset).

In most cases, this de-tokenization is enough to ensure we get back the same set of options as we would if we stored them as a list. However, in the rare case that any of the above sets is *exactly* identical to another, it gets de-duped upon flattening.

Since the right-most option should win, this change makes it so, that after de-duping, the right-most occurrence is preserved. A depset always performs left-to-right traversal, so all we need to do is add the above 5 sets of options in reverse order, and then reverse once more after flattening.

PiperOrigin-RevId: 573895869
Change-Id: Id4758597e6d93fe5c71856a742915cafc1287a68

We need this until #19829 is fixed.

This should unblock #18262.

Closes #19830.

PiperOrigin-RevId: 573892609
Change-Id: I944901a2be6c5a0cb9279dc86edc0741f3129769

- keep only one function to get split prerequisites that returns `ConfiguredTargetAndData` and modify users to get `ConfiguredTarget` from it.
- remove `getPrerequisiteMap()`

PiperOrigin-RevId: 573886458
Change-Id: Ic4dbf5add0ccebd39e4c00492c4fd51d283d8f09

Also add a note about how to update the lockfile.

Closes #19796.

PiperOrigin-RevId: 573850818
Change-Id: Iee09ccad949b692359f1280ee42cf6752e9bd5ac

Move this check to also cover native aspects evaluation, otherwise it evaluates the visibility of the tools of the underlying target rule against the target itself.

PiperOrigin-RevId: 573850253
Change-Id: I69beb6542128338fe859d2978d29018731fc1258

Supporting this combination of features wouldn't be too hard - as far as I know, we'd just have to set up the `GraphInconsistencyReceiver` properly. However, we don't intend to run these features together yet, so might as well prohibit it until we need it.

PiperOrigin-RevId: 573849045
Change-Id: I8bc91b9c5fa57b89b605fbe175755e945feb9e81

RELNOTES: None
PiperOrigin-RevId: 573840190
Change-Id: I0b6055c73ba396609bf3403067848d13edf96120

Bazel tests status:

- Bzlmod disabled:

  - AnalysisTestCase: to be migrated
  - ConfigurationTestCase: to be migrated
  - ConfigCommandTest: to be migrated, probably blocked by a bug

- Bzlmod enabled:

  - BuildViewTestCase: migrated at https://github.com/bazelbuild/bazel/commit/d51144c811bc4360aad812deae557e7c7fc32fc2
  - Java integration tests migrated at https://github.com/bazelbuild/bazel/commit/8d0471137361405d4903a9c24122b3cf327111b2
  - Shell integration tests migrated at https://github.com/bazelbuild/bazel/commit/175a18dc9f58ba40e287336e06a26617a0becd0a (Bzlmod disabled in some tests)
  - Python integration tests migrated at https://github.com/bazelbuild/bazel/commit/50c8375982085d9cf80650a62ac7065ba5f46259 (Bzlmod disabled in some tests)
  - BuildIntegrationTestCase: migrated in this change
  - Other Java unit tests migrated in this change

Issues identified:

- cc_shared_library doesn't work well with Bzlmod: https://github.com/bazelbuild/bazel/issues/19822
- `bazel config` doesn't work well with Bzlmod: https://github.com/bazelbuild/bazel/issues/19823

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

Tracking migration of remaining test cases in https://github.com/bazelbuild/bazel/issues/19824

RELNOTES[INC]: Bzlmod is enabled by default, please consider migrating your external dependencies from WORKSPACE to MODULE.bazel. Find more details at https://github.com/bazelbuild/bazel/issues/18958

PiperOrigin-RevId: 573827480
Change-Id: I097b4bd7caafc996b034284ee688b8f3d2bca1f7

PiperOrigin-RevId: 573823647
Change-Id: Ia0b5f521c5d329f33fd6fa780d79b87340c0d019

`PathMapper`s rewrite paths in command lines to make them more cache friendly, which requires executor support to stage files at the rewritten paths. This commit wires up the `PathMapper` used by a given `Spawn` in `RemoteExecutionService`, which ensures that paths of inputs and outputs are correctly mapped before being sent off to the remote executor and mapped back to the correct local paths when downloading the results.

An end-to-end test will be added in #18155, but requires #19718, #19719, and #19721.

Work towards #6526

Closes #19721.

PiperOrigin-RevId: 573806130
Change-Id: Ibbd4ff641eb301d78f5ec54813e65788d786fcea

The former was very simple and had no uses other than through the latter so it was not a very useful abstraction.

RELNOTES: None.
PiperOrigin-RevId: 573800427
Change-Id: I33ff7fdc7044107f0c087384e1e1e2294059e107

Importantly, `java_plugin` was missing the attribute.

PiperOrigin-RevId: 573799700
Change-Id: I31620dadbdf4c76777edd43b138f7b7c491b4670

RELNOTES: None.
PiperOrigin-RevId: 573777234
Change-Id: I33bb1e44c959caa6e035a9be3ce218ffcaf05363

Thus, ActionMetadataHandler is not really an appropriate name anymore, but let's do the mechanical rename in a followup change (or else merge with OutputStore, I haven't quite decided yet)

RELNOTES: None.
PiperOrigin-RevId: 573775333
Change-Id: If27cc2699fa976b9d2979aff6f63a1e51c1d5a04

`LocationExpander` and `Expander` behave differently wrt `$` escaping

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

PiperOrigin-RevId: 573768825
Change-Id: I59a13d85d1e466fb70f6bca8df3c173101ade52d

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

Closes #19725.

PiperOrigin-RevId: 573751305
Change-Id: I9b5df85dc5e52822b3a0b44fc42d90b727a5abf0

This mechanism was necessary due to an oddity of the action graph: normally, every input file an action requires is a direct dependency of that action. This didn't use to be the case in one single scenario, C++ header files: these are not necessarily inputs of the action (they are discovered by include scanning) and this used to be expressed by hiding them behind a scheduling middleman action.

This, coupled with the fact that Skybuild only guarantees that the direct dependencies of an function are available (but not transitive ones), sometimes necessitated Skyframe restarts.

Now scheduling middlemen are gone and headers are also direct (ignoring ArtifactNestedSetValue) Skyframe dependencies of C++ compilation actions, so these restarts can't happen anymore and thus the code is not necessary, either.

It's also probably unnecessary for ActionFileSystem to call env.getValue() and the same thing could be implemented by collecting the same data from the SkyValue of the scheduling dependencies, but that requires some more thinking; it's not obvious how to do that without creating too much garbage.

RELNOTES: None.
PiperOrigin-RevId: 573729592
Change-Id: Id169bbcc3df9f8e92bfab1046b3c4aa7a5da734d

Open source the allowlist enable_starlark_dex_desugar_proguard to be used in rule android_binary dex/desugar/proguard starlarkification.

PiperOrigin-RevId: 573333733
Change-Id: Ic5193a32e28f0b0fca08a54f75b8a13dc1825567

Uses pre-existing --experimental_platforms_in_output_dir (boolean).
Adds --experimental_use_platforms_in_output_dir_legacy_heuristic (boolean)
Adds --experimental_override_name_platform_in_output_dir (allows_multiple, list of Label, String)

If --noexperimental_platforms_in_output_dir (currently the default), then legacy behaviors are retained where --cpu leads the output path mnemonic and --cpu is always excluded from the ST-hash.

If --experimental_platforms_in_output_dir is on, then the --platforms value is used  to lead the output path mnemonic and --platforms is excluded from the ST-hash.

Note that if --platforms is empty, then the host platform defined by --host_platform is used. So the effective platform is never considered empty.

The scheme currently used is as follows (in descending priority order):
1. If the platform is a Label in --experimental_override_name_platform_in_output_dir, then the String from the last pairing is used. (Since last, can experiment with command-line updates of values specified in blazerc file)

2. Not-yet-implemented read from platform() declaration in BUILD (see future work below).

3. If --experimental_use_platforms_in_output_dir_legacy_heuristic is false, this skip is skipped. (Currently defaults to true for backwards compatibility reasons)
The name of the platform label (the part after the colon) is used unless that name is one of ‘default platform’ by being one of: “host”, “host_platform”, “target_platform”, “default_host”, or “default_target”. In those cases, it uses the cpu flag.

4. As the last fallback, the shortname used is 'platform-%X' where %X is the hexadecimal representation of the hash code of the unambiguous canonical form of the platform Label.

If --experimental_output_directory_naming_scheme=diff_against_dynamic_baseline, then the chosen baseline will have its platform changed to the current platform and then have platform_mappings applied. Thus, while the --cpu is no longer directly excluded from the ST-hash, if the platform_mappings is properly typing --platforms to --cpu, --cpu will effectively be excluded from the ST-hash.

Future work will allow for registering a shortname in the platforms() BUILD declaration itself. (Exact API is pending as well as plumbing that information from BuildConfigurationFunction to OutputPathMnemonicComputer.)

Compatibility:
All behaviors gated on pre-existing --experimental_platforms_in_output_dir being true, which defaults to false. There are few known pre-existing users of this flag as it is still in the 'highly experimental' phase of implementation.

Pre-existing users of experimental_platform_in_output_dir may see some slight shifts in behavior depending on how their platform_mappings are setup as the guaranteed ST-hash exclusion has changed from the --cpu to the --platform.

PiperOrigin-RevId: 573322945
Change-Id: I47b71b5873a7f7023e8c023f37f622f4ddce04e7

The value is changed to 4 which means that the symlink trees used by sandboxing
will be deleted  asynchronously in a thread pool that has size 1 when the build
is running and the pool will grow to 4 when the server is idle.

RELNOTES:Symlink trees created by sandboxing will be deleted asynchronously.
Disable behavior with --experimental_sandbox_async_tree_delete_idle_threads=0.
PiperOrigin-RevId: 573290819
Change-Id: Ib344c4fece3bc405dec835ce26dc98edb50feee5

When defining a platform (for RBE); [remote_execution_properties](https://bazel.build/reference/be/platforms-and-toolchains#platform.remote_execution_properties) is marked as deprecated, thus we do not set it. If it is not set getPlatformProto does not read the execProperties instead, before defaulting to defaultExecProperties.

Closes #19792.

PiperOrigin-RevId: 573278209
Change-Id: Ifadf043fe728ce602904db576785e1a4473b0037

Unblocks a `rules_java` update to 6.5.1 or later and thus https://github.com/bazelbuild/bazel/pull/18262, https://github.com/bazelbuild/bazel/issues/19598, and https://github.com/bazelbuild/bazel/issues/19537.

Closes #19791.

PiperOrigin-RevId: 573244082
Change-Id: I9dea195e97045b5755ed206302cec1a11f97c6e2

PiperOrigin-RevId: 573236745
Change-Id: I446b264fe29e50df5cca7d72c794aa32981215f1