The rule and legacy toolchain selection is deprecated since Bazel 7. I think it's ok to remove it now.

PiperOrigin-RevId: 791647758
Change-Id: I954f7825603d4383e3445cb5f9ce7df132565c9d

…e_libraries

This is needed to convert CcInfo to Starlark without causing a major regression.

Mark the field as legacy, because we'll need to eventually clean it up.
Upgrade rules_java, that support both old and new field location.

PiperOrigin-RevId: 792196604
Change-Id: I0cee6887a9adf5e91490fa8cfc58f51c63478f69

Bazel skylib does not have this method. This was missed in https://github.com/rules_cc/bazel/commit/8482342f7ec8029a8d890638f7ddcb4099ab41bf

Reported externally at 8482342#r163639777

PiperOrigin-RevId: 792527161
Change-Id: I48c9ce2ab296ccbe057d03aa7759c0141bd0c13e

Implements the non-generic part of the module codegen declaration.

Creation of the action as well as creation of the "compile builder"
remain in Java.

PiperOrigin-RevId: 794062119
Change-Id: Ie85c864157e1d95561d2408216ff847cbca8d25b

PiperOrigin-RevId: 794080773
Change-Id: I46d329a9f133fa4ae9e66b97c174b05d6821d4ed

…02c1f34709643f7cc872af21: Starlarkify parse header action creation and compile build variable construction

PiperOrigin-RevId: 794108507
Change-Id: I0a253f1868834c7b8154a8530fbd671c853fa236

Copybara Import from #450

BEGIN_PUBLIC
Add a raw_allowlist_include_directories cc_toolchain top argument (#450)

Apple toolchain declaration in bazel are inherently non-hermetic from a bazel perspective, as they rely on the system's Xcode installation. As a result, apple_support currently make use of
cxx_builtin_include_directories to add known system directories, as seen in the toolchain declaration here:
https://github.com/bazelbuild/apple_support/blob/master/crosstool/osx_cc_configure.bzl#L136

This currently cannot be done in rules based toolchain, as the allowlist_include_directories argument in cc_args() requires a DirectoryInfo provider.

In this change, we're adding a new top-level
raw_allowlist_include_directories parameter to the cc_toolchain() macro and to the underlying cc_toolchain_config() rule. This parameter will act just like the existing one, but will accept raw strings that will be added directly to cxx_builtin_include_directories.

Fixes #242

Closes #450
END_PUBLIC

COPYBARA_INTEGRATE_REVIEW=#450 from ma-oli:raw_allowlist_include_directories d4076e4
PiperOrigin-RevId: 794358089
Change-Id: I92e622b549fb38fd1f798efaeb119afcefc4ccb7

Previously even though the attribute was named `includes` it was passed
through the `system_includes` field of the compilation context. This
resulted in toolchains passing these include paths with `-isystem`,
which is unexpected if you use this for first party code.

Many non bazel-first projects have header directory structures that
require custom include paths be propagated throughout the graph, the
alternative to `includes` is to use `strip_include_prefix`. The downside
of `strip_include_prefix` is that you add 1 include path per
`cc_library`, even if the libraries are in the same package. With
`includes` these are deduplicated. In the case of LLVM using `includes`
reduced the number of search paths on the order of hundreds.

If users want to use `-isystem` for third party code that uses
`includes`, they can pass `--features=external_include_paths --host_features=external_include_paths`

If there are first party libraries users want to use `-isystem` with,
they can use `features = ["system_include_paths"]`

Fixes bazelbuild/bazel#20267

RELNOTES[INC]: Use `-I` instead of `-isystem` for `cc_library` / `cc_binary` `includes` attr. To use `-isystem` for only external repositories, you can pass `--features=external_include_paths --host_features=external_include_paths`. To use `-isystem` for a single `cc_library` / `cc_binary` `includes`, you can set `features = ["system_include_paths"],` on the target

Closes #25750.

PiperOrigin-RevId: 797026593
Change-Id: Icdb8f1340e683b04687a029a80b994bf433de5b0

Copybara Import from #464

BEGIN_PUBLIC
Add dwp cc_action_type (#464)

This corresponds to
bazelbuild/bazel@999e50f
so you can use fission with a rules based toolchain by adding dwp to
your tools.

Closes #464
END_PUBLIC

COPYBARA_INTEGRATE_REVIEW=#464 from keith:ks/add-dwp-cc_action_type 5651be3
PiperOrigin-RevId: 797085344
Change-Id: Ia3588e041358fe89c3cb68a7527bd0f8b1e97e67

 - Make all starlark accessible members struct fields. This is necessary because the config is written to a file via `proto.encode_text` which errors out on functions for `StarlarkInfo`. (`NativeInfo` is special-cased to ignore methods)
 - Stop converting tool paths and make variables to pairs/tuples to match the eventual Starlark implementation.
 - Update tests to access `CcToolchainConfigInfo` via the provider type instance instead of the provider key. This will allow using a `StarlarkProviderWrapper` for the Starlarkified provider.

PiperOrigin-RevId: 797683393
Change-Id: Icbc8d6c9b115a576bde3b1c3a9f2e753738969b3

Copybara Import from #421

BEGIN_PUBLIC
Add `requires-darwin` in default test runner (#421)

This was missed in 5202ddc for parity with the legacy `cc_test` flow.

Closes #421
END_PUBLIC

COPYBARA_INTEGRATE_REVIEW=#421 from fmeum:test-toolchain-requires-darwin 94ebaa9
PiperOrigin-RevId: 798224481
Change-Id: Iba80d7fec417293aaf556173d4be637eb6d4c261

Fixes #470

Closes #469

PiperOrigin-RevId: 799110211
Change-Id: I2760e634fb6b019d67a7c84c60ea59432d4dadef

PiperOrigin-RevId: 799242996
Change-Id: I0e1b42032d6315f12f82a35c7468ce9a0b848272

PiperOrigin-RevId: 799534222
Change-Id: Ic8f83a98849fc0cffb10672520b5e51fbfec516e

Fixes #454

PiperOrigin-RevId: 799544215
Change-Id: Ie6bd57e5adf05fe008e92cab2aec83b55ce4d080