rules_rust
rules_rust copied to clipboard
bazelbuild
FR: have rustc_compile_action return a dictionary to more easily distinguish the returned providers
With @scentini we were thinking this could be an improvement. This will be useful to be able to distinguish between the returned providers in client code.
Isn’t this a private API currently? That sounds fine to me since it sounds low impact but it also seems providers lack a way to identify them. I’ve run into this same issue and wish there was maybe a built in label parameter on them that made them use identifiable. What do you think?
Right, it's private. However there are already folks using it despite that (not saying that's good or bad, just it exists): https://github.com/google/crubit/blob/6ff59f1d0c784440dc13ea0597c1567d95e69884/rs_bindings_from_cc/bazel_support/rust_bindings_from_cc_utils.bzl#L140 Currently the crubit maintainers absorb the maintenance bunder to use this private API. +@scentini to chime in about this private API usage.
Afterwards in the code the providers are distinguished using a bunch of hacky heuristics. The suggestion with labels would work for the providers we control; however rustc_compile_action also returns native providers such as CcInfo, which will be harder to amend with custom attribute. Hence the suggestion to have a dict keyed by the provider type, to allow usages similar to Bazel Target-s.
The point of having anything be “private” at all is so we can make changes without considering what users might consume. I think it would be great to have a public rust_Common that had a rustc_compile_action in it. If folks wanna use the API and don’t want us to break them randomly then I think the least they could do is open a feature request and get the ball rolling. If “private” didn’t do this for us I’d worry about changes being too hard to make.
That said though, I feel providers still need a way to be identified and that returning a dict is a bandaid solution (not bad, just not the ideal one).