Use file hyperlinks when outputting target names when running `cargo run --bin` and the like.

[kpbaks]

Problem

In a project with multiple binaries, examples, tests, benches or packages commands like cargo run, cargo run --bin cargo run --example, cargo test --bench will generate an error with the list of available targets and remind the user to pick one of them. This is a good user experience as it helps the user easily discover what targets are available. I think this experience could be improved if the targets where outputted using ANSI hyperlinks, where package targets would be formatted to have a hyperlink to the file path of the crates Cargo.toml and binary targets like --bin and --example would be the file path to the file containing its main function. With this the user can easily click on the target if it's unclear where the target orginates from or how its defined and have the file open in their editor.

Proposed Solution

Change print_available_targets() and print_available_packages() in src/cargo/util/workspace.rs to use Shell to format each target as a hyperlink.

Notes

No response

[kpbaks]

I have implemented the proposed solution on a local copy, and would like to contribute it if there is support for the feature being added.

[weihanglo]

That sounds like a good idea to me! We already have local path hyperlink for cargo build --timings and cargo doc. Great to expand to Cargo targets!

I will go ahead and mark it as accepted!

@rustbot label +S-accepted +A-console-output -S-triage

[weihanglo]

Unsure if iTerm2 or other popular terminal emulators have supported opening non-HTML file correctly (or at least reasonably). We love to see the test result of them before proceeding. See #12889 (comment) for the potential issue. Also see #14615 for what emulators we've tested against.

[kpbaks]

Unsure if iTerm2 or other popular terminal emulators have supported opening non-HTML file correctly (or at least reasonably). We love to see the test result of them before proceeding. See #12889 (comment) for the potential issue. Also see #14615 for what emulators we've tested against.

I only have Linux and Windows machines I can test against. Will report the results with the terminal emulators I have available to me.

[epage]

FYI this was initially mentioned in passing at #12888 (comment)

With file://, the terminal will decide how to open the files. From the testing in #15405, it sounds like that is usually the default editor.

My main concern was custom formats. Reading over the notes for ripgrep (BurntSushi/ripgrep#665 (comment), BurntSushi/ripgrep#2483), it sounds like custom formats were mostly used to

• specify specific editors over default
• jump straight to a specific line number

So long as we link only to files and not attempt lines (e.g. what people would likely want from diagnotic links), it seems like we can bypass that problem.

@BurntSushi anything I'm missing?

[BurntSushi]

It was a while ago for me now and all that has been flushed out of cache. I think I included line numbers as a fundamental requirement, so I'm not sure how much I tested just normal file:// links and how well those are supported. But this is what ripgrep uses: https://github.com/BurntSushi/ripgrep/blob/de4baa10024f2cb62d438596274b9b710e01c59b/crates/printer/src/hyperlink_aliases.rs#L4-L22

IIRC, there was also WSL shenanigans. See https://github.com/BurntSushi/ripgrep/blob/de4baa10024f2cb62d438596274b9b710e01c59b/crates/core/flags/hiargs.rs#L1384-L1392 and https://github.com/BurntSushi/ripgrep/blob/de4baa10024f2cb62d438596274b9b710e01c59b/crates/printer/src/hyperlink.rs#L458-L459