Add a way to refer to a particular target in JSON messages

[matklad]

Package and Target are two important internal datastructures in Cargo, and we expose them for tools via various JSON messages.

To refer to a pacakge, we use an opaque in theory PackageId string. We don't have an obvious way to refer to a target of a package, and that I think causes problems.

Specifically, I think we have three places which would like to refer to targets, and each does it in its own way:

• In Artifact, we refer to target by just printing the whole target
• In cargo metadata, we don't refer to targets from resolve deps at all, but we probably should
• In the build plan PR, we print TargetKind, which is ambiguous.

Possible solution

• Just use the whole target as in Artifact, everywhere (on the one hand, this seems kind-of inelegant and duplicate, on the other hand, this is simple and straightforward)

• Use path to root file as a target_id, or (if that's ambigious), a pair of kind, path

[matklad]

@alexcrichton curious what do you think about this? I think that the second option is best:

• add target_id(&self) -> String method to Target, which uses path and kind to produce an "opaque" string, sort-of like package_id works

• add id field to the output of metadata for the Target JSON object

• do the same for the Target inside Artifact

• replace TargetKind with TargetId in build plan.

• When outputting dependencies in cargo metadata, produce deps per package and target, and not just per package.

[alexcrichton]

I think one of the problems as well is that Target doesn't really need to be identified (as it's still ambiguous). Rather a Unit in the backend (and the Artifact I believe) encompasses other things like Profile.

I do think, though, we could easily add a target_id returning a String which is pretty opauqe by including a hash of the whole structure at the end

[matklad]

Rather a Unit in the backend (and the Artifact I believe) encompasses other things like Profile.

That's true, but Unit and Artifact can be thought of as target + other stuff, so it's still might be useful to include id of the target from Cargo.toml. That is, I don't want to include profile in target_id.

Am I correct that for dependencies case, target as in Cargo.toml is the correct abstraction? That is, that the set of extern crates visible does not depend on the Unit which the target belongs to?

[alexcrichton]

Ah yeah makes sense. And yeah I believe you're right, a target is actually just a crate and only crates have dependencies on other crates :)