[7.2.0] Cherry-picks for starlarkifying all repo rules #22133
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…/foo:bar" cquery acquired this behavior 4 years ago in unknown commit, but it was never ported to aquery. This fixes some potentially surprising behavior when multiple configured targets corresponding to the same label are present (see added test cases). RELNOTES: aquery: `//foo:bar` now means "all configured targets with label `//foo:bar`" instead of "choose an arbitrary configured target with label `//foo:bar`". This is in line with cquery behavior. PiperOrigin-RevId: 620091100 Change-Id: Ib5c5ee33e35fe7ac30bc31f703b119dec40185b7
Added `local_repository` and `new_local_repository` as Starlark repo rules under `@bazel_tools//tools/build_defs/repo:local.bzl`. They're drop-in replacements for their native counterparts. Work towards #18285. RELNOTES: The `local_repository` and `new_local_repository` repository rules are now available as Starlark rules under `@bazel_tools//tools/build_defs/repo:local.bzl`. They are drop-in replacements for their native counterparts, and can be used in module extensions. Closes #21681. PiperOrigin-RevId: 615926923 Change-Id: I0cc7355b011751da23f2a3aa189f120ef177e0fe
PiperOrigin-RevId: 586091870 Change-Id: I372189e8f853845ddedcfd5eb79242cabaeac69a
It became no-op in e116bae PiperOrigin-RevId: 616176650 Change-Id: Ib3829f9446e6f2a3ecffb6b044d017d24f42a28b
PiperOrigin-RevId: 617788535 Change-Id: I485211508ea9a24837b574e3bb48a7e0d25b11d7
BEGIN_PUBLIC Fix C++ unit test to use C++ toolchains This is preparation to make --incompatible_enable_cc_toolchain_resolution a no-op. All the unit tests need to work with the flag enabled. END_PUBLIC PiperOrigin-RevId: 586254632 Change-Id: I55452515e571f12eefa376718743b1f23cbdbde8
…dk_integration_test PiperOrigin-RevId: 588363296 Change-Id: I8af466628ce9c8d9175533255faef36968570aa4
PiperOrigin-RevId: 615086311 Change-Id: I349c25de5561d4b27ec35391445b7d4a0714fe54
They became no-op in e116bae PiperOrigin-RevId: 615817205 Change-Id: Id40a92daa1c1c7044f5e8618ff8f43345ecc0725
PiperOrigin-RevId: 616992341 Change-Id: I6bbc763e85f5b2e6376179098e359a2361f18c6b
* Upgrade to `platforms` 0.0.9 * `--host_platform` now defaults to `@bazel_tools//tools:host_platform`, which is an alias of `@platforms//host` * `local_config_platform` (the repo rule) now just outputs a thin wrapper; `@local_config_platform//:host` is an alias of `@platforms//host`, and `@local_config_platform//:constraints.bzl` re-exports `@platforms//host:constraints.bzl` * Removed all test mocks of `local_config_platform`. A follow-up will guard prod usage behind a flag. Work towards #8766 and #18285. PiperOrigin-RevId: 620316973 Change-Id: I6593f62569f31faee69e88a520a0f7f42009e05d
… platform repo rule #21877 happened because, even though we define `@platforms` to be the bundled version shipped with Bazel (which is 0.0.9 on HEAD), people tend to define their own versions of `@platforms` in WORKSPACE. If this ends up being a lower version (very likely), the subsequent `load` to use the `host_platform_repo` repo rule (which is a Starlark version of `local_config_platform`) will fail because that repo rule was only introduced in `platforms` version 0.0.9. To resolve this conundrum, we define a new repo `@internal_platforms_do_not_use` that _also_ points to the bundled version of `@platforms`. Nobody is likely to define this repo, so we can fairly reliably get the Starlark repo rule, and also still allow people to override the actual `@platforms` targets they use. This only affects WORKSPACE users; if `--enable_bzlmod` is set, the `@host_platform` seen by `@bazel_tools` will come from the module extension instead. Work towards #18285. Fixes #21877. Closes #21902. PiperOrigin-RevId: 622238362 Change-Id: I6335ab1bc26ba9ef54473d8a21fc5a8510a3ace5
Similar to 77469e0, we redirect the redirects/aliases generated by `local_config_plaform` to the bundled platforms repo (`@internal_platforms_do_not_use`) if Bzlmod is not enabled. Same for the `@bazel_tools//tools:host_platform` alias. Fixes #21877. Closes #22021. PiperOrigin-RevId: 625613724 Change-Id: I17940e5d4fbd8a7690d9199f80b80ceb62b53d1a
This new flag defaults to `false`. When set to `true`, native repo rules cannot be used in WORKSPACE; their Starlark counterparts must be used. Native repo rules already can't be used in Bzlmod. Work towards #18285. Closes #21913. PiperOrigin-RevId: 626410163 Change-Id: I4981cd8d99fc87d0d0b66991e563941478b40f12
The native repo rule `android_sdk_repository` used to load from `@local_config_platform//:constraints.bzl`; 74c8ca4 changed it to load from `@platforms//host:constraints.bzl`. This caused failures with WORKSPACE users, as `@platforms` might still refer to an old version of `platforms` which doesn't have the `host` package, even though `@local_config_platform` knows to redirect to the bundled, newer version of `platforms`. This CL reverts that change, so `android_sdk_repository` now loads from `@local_config_platform` again. This is fine because both are native repo rules and will be deprecated at the same time. Partially fixes #21877. PiperOrigin-RevId: 627395814 Change-Id: I5761cde3c86190d6da3e3933aa1bef18e0dcca3e
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
github-actions
bot
added
awaiting-review
Expose a single public method getToolchain(RuleContext) from CppHelper. Before several methods public methods were exposed and those were hard to follow. The new method covers both cases C++ toolchain resolution enabled or disabled. Add toolchain to StarlarkCcCommonTest. Because the new method only uses toolchains (not legacy attributes) when toolchain resolution is enabled. This is a preparation to remove incompatible_enable_cc_toolchain_resolution. PiperOrigin-RevId: 584856533 Change-Id: I6dec785e000b20d4aa26be93686fd5fdbad8ff76
github-actions
bot
removed
the
awaiting-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RELNOTES: Added a new flag
--incompatible_disable_native_repo_rulesto disable native repo rule usage in WORKSPACE. All native repo rules now have a Starlark counterpart that can be used in both WORKSPACE and Bzlmod; see #22080 for more details.