Passing bool_flag to analysistest.make infers wrong label for the given string

[keith]

Description of the bug:

When creating a custom analysistest to set specific config_settings like this:

"""Example"""

load(
    "@bazel_skylib//lib:unittest.bzl",
    "analysistest",
)

def _impl(ctx):
    env = analysistest.begin(ctx)
    return analysistest.end(env)

custom_test = analysistest.make(
    _impl,
    config_settings = {
        "//:some_setting": True,
    },
)

Where some_setting is a simple bool_flag:

bool_flag(
    name = "some_setting",
    build_setting_default = False,
)

You get this error:

ERROR: /private/tmp/skylibrepro/BUILD:9:12: On dependency edge //:test (40d9365) -|target_under_test|-> //:lib: com.google.devtools.build.lib.packages.NoSuchTargetException: no such target '@bazel_skylib//:some_setting': target 'some_setting' not declared in package '' defined by /private/var/tmp/_bazel_ksmiley/e68a004d2ac494f072d7bb5e0fb7c459/external/bazel_skylib/BUILD (Tip: use `query "@bazel_skylib//:*"` to see all the targets in that package)

This appears to be because skylib is inferring some_setting in the context of its own repo. If you prefix //:some_setting with @//:some_setting it works in this case, but if the label lives in a ruleset that might not work for other tests that run in the context of a test workspace.

It seems that skylib should accept labels here instead, but with some quick tests locally that doesn't work either.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

In this project: skylibrepro.zip run bazel test test

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

cc5889c

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

bazelisk last_green

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

Wrapping all keys into str(Label(...)) should be a workaround with Bazel 6 and later.

[fmeum]

@rickeylev I would assume but haven't verified that rules_testing is also affected by this.

[brentleyjones]

Wrapping all keys into str(Label(...)) should be a workaround with Bazel 6 and later.

That doesn't work, because they get resolved against the main repo, so get a string of //:some_setting, and breaks the same way.

Am I recalling correctly @keith?

[keith]

That seems to work in my repro case here but not the real case bazelbuild/rules_apple#2130, maybe because of the extra level of indirection there?

[fmeum]

Wrapping all keys into str(Label(...)) should be a workaround with Bazel 6 and later.

That doesn't work, because they get resolved against the main repo, so get a string of //:some_setting, and breaks the same way.

This used to be the case, but @Wyverald fixed this for Bazel 6.