`rlocation` returns different results for a target and an alias of that target.

[Pras Velagapudi]

Description of the bug:

Define a simple sh_binary called \\:foo1, and create
an alias target \\:foo2 that refers to \\:foo1.

Then create another sh_binary called \\:bar that depends on
the foo1 and foo2 target and resolves them using $(rlocation ...).

The desired behavior would be for rlocation calls on both targets
to resolve to the same path, since they represent the same resource.
However, the actual behavior is that true target returns a result,
while the alias is not found.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

See the following repository:
https://github.com/psigen/bazel-issue-15662

Which operating system are you running Bazel on?

Ubuntu 18.04.6 LTS

What is the output of bazel info release?

release 5.2.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

Related discussion and workaround in Bazel Slack:
https://bazelbuild.slack.com/archives/CA31HN1T3/p1654808996442259

Any other information, logs, or outputs that you want to share?

Workaround 1: use sh_binary to wrap the target instead of an alias:

sh_binary(
    name = "foo2",
    srcs = ":foo1",
)

Workaround 2: use skylib's native_binary to wrap the target instead of an alias:

native_binary(
    name = "foo2",
    src = ":foo1",
    out = "foo",
)

[Pras Velagapudi]

I realize now that this is even more tricky -- at the root of the issue is that rlocation does not actually know what to point to because it is resolving a file rather than the default executable entrypoint associated with the target. These just often happen to be named the same thing, enough that many examples use the two fungibly. If the executable target referenced by the alias has associated runfiles, simply copying it will not produce the intended result either.

So the solution here might involve having a way for the bash runfiles to resolve the default executable with runfiles of bazel run for an alias. I am not sure if this would require a new macro like elocation, or some way to invoke the equivalent of bazel run :foo1 from the bash script.

[Ivo List]

The solution is to use a path returned by $(rlocationpath //alias_label) used in the rule attribute (passing it to sh script). The function knows how to resolve aliases. On older Bazel versions <6, rootpath can be used.

cc @fmeum

[Fabian Meumertzheim]

What @comius said, just want to add that rlocationpath is already in Bazel 5.4.0.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[Pras Velagapudi]

Thanks guys. It was pretty hard to find examples of this usage anywhere. For other folks looking for it, see the documentation here

I am not sure where the best documentation outside of this is.