Fix rust-project.json generation in subpackages

[hlopko]

This PR fixes a bug in gen_rust_project where we assumed that rust-project.json is generated directly under bazel-bin. For rust_analyzer targets deeper in the workspace tree that is not correct and this PR correctly descents into the right package in bazel-bin to find the rust-project.json.

I'm amazed how well I nerdsniped myself into writing a label parsing library in Rust. How hard can it be, though I. Foolish me.

[hlopko]

CC @djmarcin

[UebelAndre]

Why make this two different targets?

[hlopko]

I'm a fan of small targets. I agree that this might be over the line :)

[UebelAndre]

I too am a fan but don't think each module needs to be a separate Bazel target. I'd opt to combine these unless you feel they're isolated enough that it warrants being separated

[djmarcin]

Thanks for doing this PR.

Just throwing my two cents in on naming -- I like small targets but I think rust makes it un-ergonomic due to how it handles crate imports.

The first problem is that small targets are prone to naming conflicts -- any other package named label would result in needing to alias one of them so that you could use the right one in your code.

The second problem (not really unique to small targets) is that the name gives absolutely no indication of where a package comes from. This isn't a problem if everything just comes from crates.io, but it is a problem if it comes from some directory in a monorepo. In order to figure out where the relevant code is you have to look at the BUILD file, which isn't ideal.

One workaround is to name these targets with their full path, e.g. name = "util_label" so that when used in rust it looks like use util_label which gives you an indication of where it exists in your directory tree, but it's unsatisfying to have to do this in your BUILD files (and prone to getting out of date if you move targets around). Another idea would be for the bazel rules themselves to embed this directory information into the crate name, but that's a rather large breaking change to the existing rules. This probably isn't the right place to have this discussion, but food for (future) thought.

[hlopko]

Sounds good, I merged label with label_error.

I agree that there is a tension between small crates and unique names, and changing the rules to include package name in crate name crossed my mind in the past. I consider this problem not yet solved.