Support abbreviating --release as -r

[joshtriplett]

Of the options people regularly pass to cargo, --release seems by far
the most common. Yet even on the command line, we expect people to type
out --release.

Add a short version -r, and add some tests in the testsuite that
confirm it works.

[rust-highfive]

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

IIRC we have actually quite few short flags in Cargo right now, mostly just because we were originally pretty conservative. Ideally though this would also include -d for cargo build --dev and perhaps -p for cargo build --profile as well, although this could also easily snowball into reviewing a short flag for all existing flags which may be a bit too much to bite off at this juncture.

In any case this seems fine by me at least in spirit. I sort of want to greedily call this cargo build -O instead of -r even though -r makes sense. That probably too "cutesy" though to actually take seriously.

[joshtriplett]

I actually seriously considered -O, so it's not just you. But given that you can change the optimization level of the release profile (though I don't imagine most people would), and given that people are used to typing out the long option, I think -r would be more understandable.

Is build --dev common? Isn't that the default?

-p for profile seems confusing given -p for package as used in other commands.

But in any case, I do think we should consider more short options for things people type quite often.

[alexcrichton]

Nah --dev I don't believe is really all that common at all, I was mostly considering for symmetry. Also you're right that --profile conflicts with -p as --package so we can't add that. In that case this seems reasonable to me and there's not necessarily anything else obvious to add at this time.

@rfcbot fcp merge

[rfcbot]

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.

[rfcbot]

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

[ehuss]

Can you update the man pages?

I do have some reservations about this, but not enough to block it. I'm generally not a big fan of short flags as they can be difficult for people who are not closely familiar with the tool. It can be difficult to search for what they mean. If too many flags are shortened, then it can end up with a soup of options that can be difficult to understand at a glance.

Usually I don't find it necessary to shorten things because in typical development I find it rare to need to type them. There are quite a few ways to avoid writing commands, such as:

• Using an IDE or editor that handles everything
• Aliases
• Command history
• Tools like cargo watch

That said, I suspect --release is probably one of the most commonly used flags that isn't already shortened.

[joshtriplett]

@ehuss Sure, I'll update the documentation.

FWIW, I do think long options help make command lines more self-documenting, and I think they're generally preferable in contexts like scripts or samples. And I do regularly use history to avoid retyping this. I just also type it out enough (and see people type it out enough) to think it's worth having the option of a standard abbreviation.

[ehuss]

Thanks!

@bors r+

[bors]

📌 Commit c92d917 has been approved by ehuss

[bors]

⌛ Testing commit c92d917 with merge cf474a5...

[bors]

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing cf474a5 to master...