Adopting --incompatible_enable_proto_toolchain_resolution

[alexeagle]

This flag, introduced in Bazel 7 and advertised in the 6.0.0 release of rules_proto, allows users to avoid building the cc_binary target @com_google_protobuf//:protoc from source. This makes builds faster, reduces warnings spam in the Bazel log, and in cases where a codebase has no C++ code, it removes the dependency on a functional C++ toolchain.

However, as long as any hard-coded references to @com_google_protobuf//:protoc are reachable via the dependency graph, the benefit of the flag is negated.

End-users are the ones affected, but are not in a position to fix: they'll need to discover these bad dependency edges, isolate where the problem should be addressed, and find/file an issue on some ruleset. This discussion is meant to collect some practices for doing this, and a list of known issues.

To find why you depend on protoc:

bazel cquery 'somepath("//...", "@com_google_protobuf//:all")'

FYI @fmeum and @jiawen who are helping to facilitate the migration.

[alexeagle]

KNOWN ISSUE:
stardoc bazelbuild/stardoc#221

[fmeum]

Migration advice: References to @com_google_protobuf needed for backwards compatibility with --noincompatible_enable_proto_toolchain_resolution can be wrapped in these helper functions.

[alexeagle]

rules_swift: bazelbuild/rules_swift#1203

[alexeagle]

rules_go:
already fixed in bazel-contrib/rules_go#3919 - waiting for release

[alexeagle]

rules_rust: bazelbuild/rules_rust#2627

[alexeagle]

rules_python: was fixed by bazelbuild/rules_python#1577 and released in 0.32.0

[alexeagle]

This was reverted by bazelbuild/rules_python#1933 which deleted the code we fixed. Will try again to fix in the protobuf repo :(

[alexeagle]

rules_ts: already fixed in aspect-build/rules_ts#608 - Released in v2.4.0

[ar3s3ru]

grpc-java: grpc/grpc-java#11152

[alexeagle]

protobuf itself: protocolbuffers/protobuf#17075