Clean up and remove toolchain transition code

[katre]

The toolchain transition is now the default: it's time to clean up the code and remove it.

1. Remove uses of incompatible_use_toolchain_transition.
2. Remove uses of the flag incompatible_override_toolchain_transition.
3. Remove the code and the flag!

[katre]

Repositories that appear to need cleaning:

• https://github.com/bazelbuild/rules_cc/
• https://github.com/bazelbuild/rules_go
• https://github.com/bazelbuild/rules_nodejs
• https://github.com/bazelbuild/rules_pkg
• https://github.com/bazelbuild/rules_rust
• https://github.com/bazelbuild/rules_scala
• https://github.com/bazelbuild/rules_swift
• https://github.com/bazelbuild/tulsi
• https://github.com/angular/components
• https://github.com/google/deepvariant
• https://github.com/google/xls
• https://github.com/grpc/grpc
• https://github.com/kythe/kythe
• https://github.com/p4lang/p4c
• https://github.com/protocolbuffers/upb
• https://github.com/tensorflow/runtime

[keith]

What is the recommendation for rules that want to continue supporting bazel 4.x?

[katre]

Bazel 5.0 has been cut and will be released shortly. If you want to delay merging these PRs until that happens and support Bazel 4.x until then, that's fine. If you want to reject this PR and continue to support Bazel 4.x, that is also fine. However, note that the incompatible_use_toolchain_transition parameter will be removed before Bazel 6.0 is released.

[jsharpe]

Repositories that appear to need cleaning:

• https://github.com/bazelbuild/rules_cc/
• https://github.com/bazelbuild/rules_go
• https://github.com/bazelbuild/rules_nodejs
• https://github.com/bazelbuild/rules_pkg
• https://github.com/bazelbuild/rules_rust
• https://github.com/bazelbuild/rules_scala
• https://github.com/bazelbuild/rules_swift
• https://github.com/bazelbuild/tulsi
• https://github.com/angular/components
• https://github.com/google/deepvariant
• https://github.com/google/xls
• https://github.com/grpc/grpc
• https://github.com/kythe/kythe
• https://github.com/p4lang/p4c
• https://github.com/protocolbuffers/upb
• https://github.com/tensorflow/runtime

@katre you've missed rules_foreign_cc from this list.

[jsharpe]

Bazel 5.0 has been cut and will be released shortly. If you want to delay merging these PRs until that happens and support Bazel 4.x until then, that's fine. If you want to reject this PR and continue to support Bazel 4.x, that is also fine. However, note that the incompatible_use_toolchain_transition parameter will be removed before Bazel 6.0 is released.

So what you're essentially saying here then is that it's not going to be possible for rules to support bazel version 4.x through 6.x in a single release of the ruleset? Given the LTS support windows for bazel 4.x and bazel 6.x overlap isn't this pushing rules authors to end support for 4.x in their rules earlier than LTS support for version 4.x runs out? I know that the LTS model only applies to bazel itself and not the rules but it does have implications on what the wider community decide to support. @alexeagle this is probably the kind of change that the core team need to communicate to the rules authors SIG as, as highlighted above, not all the repos that are affected have been caught.

[alexeagle]

Yes and also, you shouldn't send PRs to rulesets that break their compat with LTS.

[katre]

Valid points from everyone. I think I've jumped the gun on this change, apologies.

I'm going to close out the PRs (and ask owners of the ones that merged if they want to revert), and I won't send these until later.

I will also leave the incompatible_use_toolchain_resolution argument to rule() as a no-op until just before 6.0 is cut.

This should allow rules to keep the parameter and be compatible with 4.x and 5.x.

However, I do want to get this functionality removed from Bazel so that I can clean up old code and flags in the near future.

[katre]

(Note that the google-internal version of this will continue, but any rules which are vendored into google's repo can refuse the change and stay as they are).

[jsharpe]

I guess this does raise the interesting question of what LTS support is in the context of supporting an incompatible flag being turned on for a version.

One could make the case that the incompatible flag in bazel 4.x that requires this argument doesn't fall under LTS support and thus that removing this code from rules targeting 4.x is still a valid thing to do, but guess that is a wider question for discussion by the product team?

[katre]

Finished most of the cleanup, still waiting on bazelbuild/rules_java#163 and a few google-internal changes before I can submit the change to remove the parameter.