Skip to content

Conversation

@gregestren
Copy link
Contributor

Cherry-pick of 054536e:

This avoids a common gotcha in which a select in a macro with repo names in string keys will generally not work correctly when loaded in the context of a different Bazel (Bzlmod) module that uses a different set of apparent names.

In the rare case where resolution relative to the loading BUILD file is necessary (e.g. in Skylib's selects.config_setting_group or other macros that generate config_settings and selects referring to them), the keys can be preprocessed with native.package_relative_label.

RELNOTES: With the new --incompatible_eagerly_resolve_select_keys flag, the label string keys of select dicts in .bzl files are resolved relative to the containing file instead of relative to the BUILD file that ends up using the select. Use native.package_relative_label if this is not desired.

For #26216.
Closes #26223 (comment)

fmeum and others added 2 commits October 27, 2025 16:28
This avoids a common gotcha in which a `select` in a macro with repo names in string keys will generally not work correctly when loaded in the context of a different Bazel (Bzlmod) module that uses a different set of apparent names.

In the rare case where resolution relative to the loading `BUILD` file is necessary (e.g. in Skylib's `selects.config_setting_group` or other macros that generate `config_setting`s and `select`s referring to them), the keys can be preprocessed with `native.package_relative_label`.

RELNOTES: With the new `--incompatible_eagerly_resolve_select_keys` flag, the label string keys of `select` dicts in `.bzl` files are resolved relative to the containing file instead of relative to the BUILD file that ends up using the `select`. Use `native.package_relative_label` if this is not desired.

Closes bazelbuild#26216.

PiperOrigin-RevId: 811342967
Change-Id: I8a806ae9b94db248bcb18460984f6b418a1284d6
@gregestren gregestren requested a review from a team as a code owner October 27, 2025 17:15
@github-actions github-actions bot added team-Documentation Documentation improvements that cannot be directly linked to other team labels awaiting-review PR is awaiting review from an assigned reviewer labels Oct 27, 2025
if (labelConverter == null) {
StarlarkThreadContext ctx = thread.getThreadLocal(StarlarkThreadContext.class);
var targetDefinitionContext = ctx instanceof TargetDefinitionContext tdc
? tdc
Copy link
Contributor Author

@gregestren gregestren Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this from

public static TargetDefinitionContext fromOrNull(StarlarkThread thread) {
StarlarkThreadContext ctx = thread.getThreadLocal(StarlarkThreadContext.class);
return ctx instanceof TargetDefinitionContext targetDefinitionContext
? targetDefinitionContext
: null;
which doesn't exist in 8.x.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the idiomatic Bazel 8-era way of saying this is

          Package.Builder pkgBuilder = Package.Builder.fromOrNull(thread);
          if (pkgBuilder != null) {
            labelConverter = pkgBuilder.getLabelConverter();
          }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated. Thanks.

public void testKeyResolution(@TestParameter boolean resolveSelectKeysEagerly) throws Exception {
var ctx =
BazelModuleContext.create(
Label.parseCanonicalUnchecked("//other/pkg:def.bzl"),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simplified from

BazelModuleKey.createFakeModuleKeyForTesting(
Label.parseCanonicalUnchecked("//other/pkg:def.bzl")),
- BazelModuleKey doesn't exist in 8.x.

@gregestren gregestren removed the team-Documentation Documentation improvements that cannot be directly linked to other team labels label Oct 27, 2025
@gregestren gregestren requested a review from fmeum October 27, 2025 17:47
@gregestren gregestren added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Oct 27, 2025
Copy link
Contributor

@tetromino tetromino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo the nit in SelectorList.java

if (labelConverter == null) {
StarlarkThreadContext ctx = thread.getThreadLocal(StarlarkThreadContext.class);
var targetDefinitionContext = ctx instanceof TargetDefinitionContext tdc
? tdc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the idiomatic Bazel 8-era way of saying this is

          Package.Builder pkgBuilder = Package.Builder.fromOrNull(thread);
          if (pkgBuilder != null) {
            labelConverter = pkgBuilder.getLabelConverter();
          }

@iancha1992 iancha1992 added this pull request to the merge queue Oct 28, 2025
Merged via the queue into bazelbuild:release-8.5.0 with commit ef394f4 Oct 28, 2025
46 checks passed
@github-actions github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Oct 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants