Open illicitonion opened 1 year ago
/cc @gregestren @fmeum @sdtwigg
@gregestren Please triage this, it may be related to your work on cquery and aspects.
I generally think cquery accuracy issues are from aspects or toolchains (https://github.com/bazelbuild/bazel/issues/16310) but @illicitonion mentions neither are relevant here.
To be clear, do you think this is specifically an issue with --output=jsonproto
? Does this look similar with default output formatting?
[Edited - I was looking at an incorrect target]
No, it doesn't look specific to the output format, exactly the same is present in the default output format
//:epb_go_proto (7dbfde3)
proto#//:epb_proto#(Starlark transition:/private/var/tmp/_bazel_dwagnerhall/2cc5552d5ea0ab87cc9070d7832c1463/external/io_bazel_rules_go/go/private/rules/transition.bzl:255:36 + (TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> 7dbfde3
compilers#@io_bazel_rules_go//proto:go_proto#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7dbfde3
$go_context_data#@io_bazel_rules_go//:go_context_data#(Starlark transition:/private/var/tmp/_bazel_dwagnerhall/2cc5552d5ea0ab87cc9070d7832c1463/external/io_bazel_rules_go/go/private/rules/transition.bzl:175:37 + (TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> 7f452ad
$allowlist_function_transition#@bazel_tools//tools/allowlists/function_transition_allowlist:function_transition_allowlist#NullTransition ->
[toolchain dependency]#@go_sdk//:go_darwin_amd64-impl#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7dbfde3
Following $go_context_data#@io_bazel_rules_go//:go_context_data#(Starlark transition:/private/var/tmp/_bazel_dwagnerhall/2cc5552d5ea0ab87cc9070d7832c1463/external/io_bazel_rules_go/go/private/rules/transition.bzl:175:37 + (TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> 7f452ad
I see:
Starlark transition:/private/var/tmp/_bazel_dwagnerhall/2cc5552d5ea0ab87cc9070d7832c1463/external/io_bazel_rules_go/go/private/rules/transition.bzl:175:37 -> @io_bazel_rules_go//:go_context_data (7f452ad)
cgo_context_data#@io_bazel_rules_go//:cgo_context_data#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7f452ad
coverdata#@io_bazel_rules_go//go/tools/coverdata:coverdata#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7f452ad
go_config#@io_bazel_rules_go//:go_config#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7f452ad
nogo#@io_bazel_rules_nogo//:nogo#(exec + (NoTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> a22f584
stdlib#@io_bazel_rules_go//:stdlib#(Starlark transition:/private/var/tmp/_bazel_dwagnerhall/2cc5552d5ea0ab87cc9070d7832c1463/external/io_bazel_rules_go/go/private/rules/transition.bzl:277:34 + (TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> 7f452ad
$allowlist_function_transition#@bazel_tools//tools/allowlists/function_transition_allowlist:function_transition_allowlist#NullTransition ->
[toolchain dependency]#@go_sdk//:go_darwin_amd64-impl#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 7f452ad
Thanks. Got to do some more diagnosing then... Any non-format-specific accuracy issue needs to be understood.
I can't resolve https://artifacts.apple.com/github.com/protocolbuffers/protobuf/archive/v3.17.3.tar.gz
. Am I missing something obvious?
Apologies, I've edited the original post to remove the address of a private mirror of https://github.com/protocolbuffers/protobuf/archive/v3.17.3.tar.gz
Phew. I thought I was failing some basic repo mapping test. :)
It looks like it was been fixed by 9575c7fa86458717c154f08ff8a7f7aff000f6ae 🎉
That change looks very hard to backport to 6.4.0, as it has a lot of dependencies, but if anyone has any ideas for how to do so, it'd be really handy to have done!
I agree that will be hard to backport. But I still don't understand why that level of refactoring would be necessary for a bug that manifests in all output formats.
My suspicion from starting to debug this myself is that the manual implementation following split transitions wasn't also applying self transitions on the transition target, and that possibly something in that change started using more general transition-applying code which applied more of the relevant transitions, but I didn't delve super deep into the actual fix.
Description of the bug:
I am running cquery to find out, including transitions, about the dependency chain of configured targets of a
go_proto_library
.If I
bazel cquery --output=jsonproto --transitions=lite 'deps(//:epb_go_proto)'
somego_proto_library
,configuredRuleInputs
declares there's a dependency on@io_bazel_rules_go//:go_context_data
in the same configuration as the target itself.That target itself claims to have a dependency on
@io_bazel_rules_go//:stdlib
also in the same configuration.However, there is no entry in the cquery output for
@io_bazel_rules_go//:stdlib
in that configuration. That target is present in three configurations, but not the one declared.I would expect the transition following and expansion of cquery to ensure any ConfiguredTarget which appears in configuredRuleInputs is also present in the output of a
deps
query.From inspecting the relevant rules,
go_proto_library
just has a regular dependency on@io_bazel_rules_go//:go_context_data
, and then@io_bazel_rules_go//:go_context_data
self-transitions.As far as I can tell, these dependencies don't go via any toolchains, and though
go_proto_library
does have an aspect, that's not relevant for this dependency path.What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
With this WORKSPACE:
and this BUILD file:
Run
bazel cquery --output=jsonproto --transitions=lite 'deps(//:epb_go_proto)'
And inspect the output for the particular targets I've mentioned in the issue description.
Which operating system are you running Bazel on?
macOS
What is the output of
bazel info release
?release 6.1.1
If
bazel info release
returnsdevelopment 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