Add --filter-platform to cargo metadata.

[ehuss]

This adds the --filter-platform flag to cargo metadata to give users a way to filter the resolve information based on the target triple.

This is just a prototype to open for feedback. Some things that need feedback:

• Debate the name of the flag.
• It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.
• Should it also filter the dependencies in the "packages" array? Right now it only does resolve. I'm on the fence. It probably should, but that would be an intrusive change to rewrite the Package values.
• Should the filtering be transitive? That is, if a package is only reachable by a specific platform, should it be removed from the resolve "nodes"? What about "packages"? Currently it is included, with the intent that you walk the resolve starting with a root (like a workspace member). But it might be surprising to see "winapi" when you filter for a unix platform.

This will need documentation before it is merged.

[rust-highfive]

r? @Eh2406

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Well all the high-level comments I would have are covered by your questsions, so...

Debate the name of the flag.

In terms of bikeshedding UI, I think this has some overlap with #5133 since presumably if that went through it'd be added to cargo metadata and have roughly the same effect that this proposed flag already has.

It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.

I think --filter-platform host would be the same as --filter-platform $the_actual_host, right? If so I agree it's a bit out of place for here and we probably don't want to add it just here just yet.

Should it also filter the dependencies in the "packages" array?

This is where the overlap with #5133 might be more apparent because if we were to implement that then the PackageSet and Resolve would both be pre-filtered already and would already effectively dictate this. Semantically though I feel like if you're just asking for metadata about a particular target you shouldn't get winapi anywhere (or other non-relevant dependencies for your platform)

Should the filtering be transitive?

I think this is roughly the same thing as the previous question, but I may be misunderstanding some nuance you're intending that I understand. In any case I do think that it's probably best to filter everything out as aggressively as possible in the ideal world, but having extra stuff in there in an initial implementation isn't the end of the world.

[ehuss]

I've update the PR with a rewrite where it filters the entire graph. I don't think avoid-dev-deps is what we really want here, since that doesn't really handle targets (in the resolver), and we do want dev-deps listed.

I considered using build_unit_dependencies directly, but since the target filtering code is so small, I figured it wasn't worth the added complexity. If things become more complicated in the future (like with feature selection), then we might consider that approach instead.

I also removed the special host target.

This still needs documentation.

Two quirks to note:

• binary-only deps are no longer listed. I personally don't care about those (they do nothing), but I could add them back if desired, it just will be a little more awkward.
• The "dependencies" field of the Package still lists the full set of dependencies without filtering. I could go either way on that, but it's a little harder to do. The intent in my mind is that "dependencies" is exactly what is written in Cargo.toml without modification. The resolve section is the actual resolve with whatever filtering applied.

[alexcrichton]

Sorry for the delay in review, but this seems reasonable to me! r=me when you're ready to land this.

[bors]

☔ The latest upstream changes (presumably #7536) made this pull request unmergeable. Please resolve the merge conflicts.

[ehuss]

Added some documentation.

@bors r=alexcrichton

[bors]

📌 Commit ca02e03 has been approved by alexcrichton

[bors]

⌛ Testing commit ca02e03 with merge 5da4b4d...

[bors]

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 5da4b4d to master...