Add alias_label struct field to all targets

[fmeum]

This allows rules to obtain the label of an alias target rather than only the label of the target an alias chain ultimately resolves to. The former is the label as specified by the user on the rule, which can be important to know for e.g. fixup messages and manual implementations of location expansion.

Fixes #11044

[lberki]

We already have AliasProvider, why not make that available to Starlark instead?

[fmeum]

We already have AliasProvider, why not make that available to Starlark instead?

To me AliasProvider feels more like a Bazel implementation detail than an intuitive API object. I find ctx.attr.dep.alias_label in parallel to the existing ctx.attr.dep.label much more readable than ctx.attr.dep[AliasProvider].label (which would additionally need an in check for AliasProvider). Exposing AliasProvider would also allow users to restrict attributes to targets that provide it, which I don't think should be possible.

Unless there is additional alias-related logic that may need to be exposed to Starlark, a struct field on Target, I would thus prefer not to expose this information via AliasProvider.

[lberki]

FWIW, AliasProvider has the advantage that it allows one to access the full chain of aliases, not just the two labels at the end of it. I can relate to your argument, though, that it would allow the abuse you described above.

@comius do you have an opinion?

[fmeum]

@lberki Do you have an example use case that relies on the intermediate labels in the chain? I have a hard time coming up with any and wonder whether exposing this chain would really be a desirable feature. Bazel appears to only contain a single reference and that is in aspect logic.

[lberki]

To be pedantic, I didn't say that it's useful, I said that it's possible :)

Bazel uses it internally for better error reporting ("Target :a reached through alias chain :b -> :c -> :a is illegal) . "fixup messages and manual implementations of location expansion" sounds similar, although I could be easily convinced that Starlark code doesn't need to know about it.

[comius]

Could I ask for a design document here? I think there are several different ways how to implement this, several problems and APIs related to this. There's also a philosophical aspect (or call it a good design practice), that an alias should be indistinguishable from the target it points to.

I'm lacking bandwidth to do an ad hoc "design doc" in my mind, review all the surrounding code and then confirm all the implicit design decision a PR like this could be making.