Bazel 6.0.0 prefixes target label with "@" (at symbol)"

[tpasternak]

Description of the bug:

In aspects, the label field of a target is now prefixed with @//, while in 5.4.0 it was prefixed with just //. Both prefixes are correct, but this is a behavior change, which may break some tools. I'm submitting it, because I don't know whether it was intentional.

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

1. Clone this repository and checkout 6.0.0
2. Create aspect file

cat > aspect.bzl << EOF
def _print_aspect_impl(target, ctx):
    print(str(target.label))
    return []

print_aspect = aspect(
    implementation = _print_aspect_impl,
)
EOF

3. Run build with aspect

bazel build //src/test/tools:srcs  --aspects aspect.bzl%print_aspect

RESULT:
Bazel 6.0.0 prints @//-prefixed labels, while 5.4.0 just //-prefixed

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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

No response

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

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

[brentleyjones]

This is expected as part of #15916 (the --incompatible_unambiguous_label_stringification=true flag).

[tpasternak]

Thank you @brentleyjones !

[tpasternak]

Reopening, as I noticed an inconsistency, that should probably be also covered by this flag. In BEP logs, the labels are not @//-prefixed so the labels in aspects are different than the ones in BEP events. To reproduce, you can run the same command with --build_event_text_file log.txt. It will also contain some entries having label field, but these begin with //

[cpsauer]

As a heads, this also seems to be inconsistent with aquery/query (on rolling), which still uses the old form.
Does anyone know if the the plan to change those, too, or to leave them as they are?

[Happened across this, which is good, because a consistent change would have broken a tool I maintain. We'd been assuming the @ prefix of the canonical form of stringified labels could be used to distinguish external workspaces; I've now added code to remove that assumption, still assuming that @// prefixes the canonical label for targets in the main workspace.]

[fmeum]

@Wyverald can say more here, but my understanding is that without --enable_bzlmod, only the stringification of Starlark Label objects should have changed (as explained by the incompatible flag).

The need for this arose as a Label object doesn't know in which context it is printed and thus needs to be stringified in a way that unambiguously refers to the main repository. Tools such as query usually structure their output so that it is interpreted in the context of the main repository and can thus print repo-relative labels.

The fact that the empty repository name (@//...) refers to the main repository hasn't changed, so external tools should be able to reply on that.

[cpsauer]

Sweet. Thanks for being helpful as always @fmeum :)