cquery label outputs inconsistent after bazel 6

[illicitonion]

Description of the bug:

% USE_BAZEL_VERSION=5.4.0 bazel cquery --output=starlark --starlark:expr='target.label' ... 2>/dev/null
//java/example/simple:simple
//java/example/simple:simple_dep
% USE_BAZEL_VERSION=6.0.0 bazel cquery --output=starlark --starlark:expr='target.label' ... 2>/dev/null
@//java/example/simple:simple
@//java/example/simple:simple_dep

It looks like in Bazel 6, in-repo labels started stringifying with a leading @.

This is inconsistent with regular cquery output, which still doesn't have leading @s for labels:

% USE_BAZEL_VERSION=6.0.0 bazel cquery ... 2>/dev/null                  
//java/example/simple:simple (a42135a)
//java/example/simple:simple_dep (a42135a)

This means that if trying to filter cquery output based on some --output=starlark query expression (e.g. filtering out incompatible targets, as documented here), manual code needs to be written to add or strip a leading @.

It would seem useful for all cquery commands, and the native starlark label stringification, to use consistent stringification, so that simpler equality checks can be performed when processing the output.

[illicitonion]

/cc @gregestren @sdtwigg @fmeum

[fmeum]

CC @Wyverald

Getting rid of the @ would probably require wiring up the actual StarlarkSemantics in

bazel/src/main/java/com/google/devtools/build/lib/query2/cquery/StarlarkOutputFormatterCallback.java

Line 191 in 7556e11

StarlarkThread thread = new StarlarkThread(mu, StarlarkSemantics.DEFAULT);

instead of using the defaults.

Having consistent stringification across cquery output modes is challenging with Bzlmod: In the interest of emitting human-readable labels, I implemented main repository mapping "unmapping" to the default output mode. This means that canonical repository names such as @rules_go~1.2.3~go_deps~foo will be printed as @foo if the main repository declares the apparent name foo for this repo.

But in general Starlark code, the stringification of a label should always yield a canonical label string such as @@rules_go~1.2.3~go_deps~foo//.... Changing that behavior just for cquery would seem to require passing in a custom StarlarkSemantics object for cquery that includes the main repository mapping.

[aiuto]

I've also seen @ vs @@ showing up as differences across linux vs. windows, within the same bazel version.
I normalizae them to all be single @

[Wyverald]

I've also seen @ vs @@ showing up as differences across linux vs. windows, within the same bazel version.

That shouldn't be possible. (Or it's a bug that we need to fix.)

In any case, the proper way to fix for this issue is unclear to me because of what @fmeum wrote above. The StarlarkSemantics object is really just a collection of flag values; plugging in a complex data structure like the main repo mapping sounds like a big change if possible at all.

[katre]

@Wyverald Can you triage this and reassign it to the correct label?

[Wyverald]

team-Configurability isn't technically wrong since this is about cquery. But I'll keep an eye on this too.

[fmeum]

Looking into this again. Would anyone find it surprising if Labels stringify differently in cquery formatters than they do in regular Starlark if this brings us consistency with query and other cquery outputs?

[fmeum]

As noticed in bazel-contrib/rules_go#3659 (comment), there needs to be a way to match the output of str(Label(...)) to that of query and cquery.

Thus, instead of trying to force the main repo mapping into cquery --output=starlark, I think that we need a --canonical_labels flag for query and cquery that ensures that all labels in the output are in unambiguous canonical form.

[Wyverald]

I think that we need a --canonical_labels flag for query and cquery that ensures that all labels in the output are in unambiguous canonical form.

This sounds good to me. It's probably the least messy way to fix this... mess.

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!