Allow passing env to cc_tool

[dzbarsky]

This covers 2 use cases:

1. passing license file env vars to proprietary compilers
2. Exposing the location of helper binaries to cc_tool. The alternative of supplying those as env/data via cc_args doesn't work because then the binaries will be cfg=target instead of cfg=exec.

[trybka]

@armandomontanez any thoughts as SME for rules-based Toolchains?

[dzbarsky]

@armandomontanez any thoughts as SME for rules-based Toolchains?

Sorry should have shared the context, this was Armando's suggestion :) https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1770220066174189?thread_ts=1770153962.810599&cid=CGA9QFQ8H

[armandomontanez]

As ubiquitous as location expansion is, we should prefer support for the format expansion in cc_args. That has a few perks:

1. You can point at directories.
2. You can point at flags. (soon 😉)

Also, it's consistent with the prior form.

Generally speaking I don't object to also supporting expand_location() across all of these rules, but I'd prefer that to be an independent change that introduces support across all relevant parts of the API.

[dzbarsky]

okie, I updated it, PTAL

[keith]

@trybka can you check the internal CI failure here?

[trybka]

It looks like it was an already-failing test. Lemme see if it will import cleanly now.

[trybka]

From internal review:

I think it's worth mentioning here in a comment that attr.format stores things in reverse, with labels as keys and format strings as values, with a pointer to the comment where this reversal is done.

[trybka]

From internal review:

Mid term we might want to consider converting this into a symbolic macro.

(maybe add a TODO?)

[trybka]

From internal review:

It may be worth also adding a pointer here to src/main/java/com/google/devtools/build/lib/packages/Type.java;l=61 where the cost of adding a new attribute type are spelled out. I had already started to think about adding one when I hit upon this guidance.

[armandomontanez]

Admittedly, this string was copied from another such instance.

Bazel does support a string-keyed label, but not across all versions: https://bazel.build/rules/lib/toplevel/attr#string_keyed_label_dict

The version support for label_keyed_string_dict string is wider.

[dzbarsky]

Yep! Tom and I iterated in DMs and he's going to import the version with comments addressed!

[matts1]

Flipping the key-value pairs is insufficient as it won't work if you have the same value multiple times.

Rather, we should probably instead write

format_keys = list(format.keys())
format_values = list(format.values())

Then we can, in the rule itself, write format = {k: v for k, v in zip(ctx.attr.format_keys, ctx.attr.format_values)}.

[trybka]

Good callout. Presumably though, if you had the same label used twice, you could use the same place-holder, too. Do you think it would be sufficient to error in that case or would you rather implement this?

[armandomontanez]

cc_tool_map has a workaround for this problem. Probably makes sense to just break that out into a starlark helper.

rules_cc/cc/toolchains/tool_map.bzl

Lines 116 to 122 in ee57062

	deduplicated_tools = {}
	for action, tool in tools.items():
	actions.append(action)
	label = native.package_relative_label(tool)
	if label not in deduplicated_tools:
	deduplicated_tools[label] = len(deduplicated_tools)
	tool_index_for_action.append(deduplicated_tools[label])