Extract Platform to a separate crate.

[ehuss]

This moves the Platform, Cfg, CfgExpr types to a new crate named "cargo-platform". The intent here is to give users of cargo_metadata a way of parsing and inspecting cargo's platform values.

Along the way, I rewrote the error handling to remove failure, and to slightly improve the output.

I'm having doubts whether or not this is a good idea. As you can see from the examples/matches.rs example, it is nontrivial to use this (which also misses cargo's config values and environment variables). I don't know if anyone will actually use this. If this doesn't seem to have value, I would suggest closing it.

I've also included a sample script, publish.py, for publishing cargo itself. I suspect it will need tweaking, but I figure it would be a start and open for feedback.

[rust-highfive]

r? @Eh2406

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

[ehuss]

See #7376 for an alternative approach for this.

[alexcrichton]

I agree that this is pretty nontrivial and probably not a great solution for cargo metadata, but for our own internal uses and code organization I'd be in favor of splitting out the crate (and agressively doing so for other things we can find as well!).

Do you think, though, that even for pure Cargo-only purposes this still isn't worth it?

[ehuss]

If there are no objections, I'm fine with splitting it out.

Before merging, I'd like to get feedback from someone (@pietroalbini ?) on the publish script and whether it will be useful. Some notes on it:

• I can rewrite it in another language if needed, but I'm most comfortable with python.
• Before it is used the first time (on 1.40), someone will need to manually publish the first version of cargo-platform.
• It assumes you run in a clean environment (i.e., it does not include --allow-dirty). Not sure if that's ok.
• Does the dry-run pass seem OK?
• Anything else it should do?
• The "already published" check is there under the assumption that some crates like cargo-publish are expected to change very rarely. From my testing, it seems to work well enough.

[pietroalbini]

cc @Mark-Simulacrum who's going to manage the 1.38 release.

[Mark-Simulacrum]

I don't mind having it but so long as the number of crates is less than 5 or so I'm fine with manual publishing - it's not too hard to cd around and run cargo publish. The main "slowness" comes from needing to wait for the publish verification to complete so that I know I'm not doing anything wrong :)

[alexcrichton]

@bors: r+

Ok sounds good! Let's go ahead and merge this and we can figure out publication closer to the release itself if anything becomes a snag.

[bors]

📌 Commit 57c96c1 has been approved by alexcrichton

[bors]

⌛ Testing commit 57c96c1 with merge 7ab4778...

[bors]

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 7ab4778 to master...