bazel query --output=proto should include information about whether the attribute has cfg = "exec"

[timothyg-stripe]

Description of the feature request:

We would like the Attribute protobuf message in build.proto to contain a field, tentatively called cfg_is_exec, that is set to true if the attribute has the exec transition (cfg = "exec").

Which category does this issue belong to?

Configurability

What underlying problem are you trying to solve with this feature?

Context: To run static analysis checks on our code repository, we would like to run one large bazel query --output=proto, and then process its output through other tools. Most of the query language can be simulated in this way given a repo-wide query dump, along with some Bazel options like --noimplicit_deps. However, we found that the Bazel option --notool_deps cannot be simulated, since the query dump contains no information about whether an attribute has cfg = "exec" or not.

Numerous precedents exist:

• The old AttributeDefinition message (used for bazel info build-language) contains both a nodep field and a cfg_is_host field. cfg_is_host is exactly what I'm after, except the fact that bazel info build-language only supports built-in rules.
• The Attribute message already contains a nodep field, which, like the proposed field conveys some message about a property of the attribute.

---

Also: I understand that bazel cquery (+ bazel config) would give us the necessary information. However, we currently have several reasons to avoid running cquery on the entire repo.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 7.1.2

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 HEAD ?

No response

Have you found anything relevant by searching the web?

No.

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

No response

[fmeum]

Instead of just a boolean, could we maybe make this a string field that is either exec, target or //some/pkg:defs.bzl%my_starlark_transition (assuming the transition is exported)? @katre is working on chaining transitions, which could mean that an exec transition is hiding within a Starlark one.