Problem

Some Bazel native rules depend on targets that are specified via command line options, the default value of those options may point to targets in certain external repositories.
See https://cs.opensource.google/search?q=%22defaultValue%20%3D%20%5C%22@%22&ss=bazel

For example:

  @Option(
      name = "crosstool_top",
      defaultValue = "@bazel_tools//tools/cpp:toolchain",
      converter = LabelConverter.class,
      ...
      help = "The label of the crosstool package to be used for compiling C++ code.")
  public Label crosstoolTop;

@bazel_tools//tools/cpp:toolchain is essentially an alias to @local_config_cc//:toolchain.
With WORKSPACE, repository @local_config_cc is ensured to be available because we load cc_configure() in WORKSPACE suffix.

With Bzlmod, this is going to be migrated to to rules_cc, cc_autoconf(name = "local_config_cc") will still be loaded via module extension, but its canonical repo name will be @rules_cc.<version>.<extension name>.local_config_cc.

Therefore, @bazel_tools//tools/cpp:toolchain will no longer be able to locate @local_config_cc//:toolchain because @bazel_tools can only see module extension repos via canonical repo names (no repo mappings is applied). We can manually override the target by --crosstool_top=@rules_cc.<version>.<extension name>.local_config_cc//:toolchain as a workaround, but obviously we need a better solution for this.

Proposed solution

• Make bazel_tools a default Bazel module, which can depends on other normal Bazel modules (eg. rules_cc) that provides those targets required by native rules.
• @bazel_tools//tools/cpp:toolchain is still an alias to @local_config_cc//:toolchain, but this time because bazel_tools is a Bazel module, we'll apply proper repo mappings for @local_config_cc//:toolchain, then the alias could work.
• Other flags that point to repos other than @bazel_tools will have to use @bazel_tools as a bridge. For example, xcode_version_config