r? @alexcrichton

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

@alexcrichton I thought some more about the comment you left, but I really think it is better just to have a single message. I wouldn't want tools to have to listen for N messages to know when things are done. And generally I don't need to know when something launches.

We can add "launched" messages in the future if it looks like people want it. Also, I think the libtest JSON message already has a separate message for "starting", so test frameworks may already cover that need.

Seems reasonable for me to add, it's not like this will burden us with backward compatibility, and it does seem useful.

However, I do have a gut feeling that a "proper" solution here is allowing clients to split Cargo's command in two phases, building and running. Sort-of like a universal --no-run argument, so that clients can do cargo run --example foo --no-run and then either cargo run --example foo again or just run the binaries themselves. But it seems unlikely that we actually add such a --no-run flag, and, even if we do, such addition wouldn't be precluded by the BuildFinished message. We might even want to have BuildFinished message anyway, to, for example, convey the [optimized + debuginfo] in 60 seconds info in machine-redable form.

cargo build --example foo I think is 100% identical to a hypothetical cargo run --no-run. The JSON even gives you the path to the executable, so a tool can just run it directly (there might be some rare dylib path issues, but programs probably shouldn't rely on those, or the tool can just execute cargo run if it wants to be safe/simple). My tool just executes cargo run and once it sees the text ^\s*Running it stops looking for JSON messages. I can switch to looking for "build-finished" with this PR.

@rfcbot fcp merge

I'm personally ok doing this, and it also seems plausible to take the strategy that @matklad mentions but I don't think there's any reason they need to be mutually exclusive!

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @ehuss
• @joshtriplett

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

That's enough of sign-off for me, and we can always back out if there are other objections!

@bors: r+

📌 Commit c889bbf has been approved by alexcrichton

⌛ Testing commit c889bbf with merge 239f2bf...

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 239f2bf to master...