Named profile updates

[ehuss]

A few updates for named profiles to push them closer to stabilization:

• Disable the dir-name profile setting. dir-name primarily exists for translating the built-in profiles or sharing artifacts between profiles. In order to simplify the UI, we would like to not expose it to the user for the initial stabilization. The code to support it is kept in case we want to add it in the future.
• Reserve some profile names. Just to give a little flexibility in the future in case we want to use these, or that they could cause confusion. Also updated the error text a little.
• Add support for custom profiles to legacy commands. Their old behavior is still retained for backwards compatibility. That is:
  • cargo check
    • --profile=test: This forces the test mode. For example, cargo check --lib --profile=test will check the library as a unit test (with --test).
  • cargo fix
    • --profile=test: Forces test mode, same as above.
  • cargo rustc
    • --profile=test: Forces test mode, same as above.
    • --profile=bench: Forces bench mode.
    • --profile=check: Forces check mode.
  • These commands also allow mixing the above options with --release, which is normally not allowed.
• Fix cargo bench to support the --profile option. I think it was just forgotten.

[rust-highfive]

r? @alexcrichton

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

[ehuss]

During our previous meeting, we discussed the inconsistency of the legacy commands compared to other commands. Specifically, cargo rustc --profile=test will build with rustc --test flag, but cargo build --profile=test will not. We considered making it so that --profile=test or --profile=bench or any profile that inherits from those would imply the --test flag should be used. But after considering it more, I am having more doubts about that. Looking at using --profile=test with several commands:

• test and bench: These already use --test
• clean: Doesn't really matter
• install: --test doesn't make sense
• doc: --test doesn't make sense
• run: --test doesn't make sense (use cargo test instead)
• rustdoc: --test could potentially be used, but I think we should keep that as cargo test --doc

So the only command that is really questionable is cargo build. My feeling is that if we really want to support this, that there should be something like a --mode flag to explicitly switch the mode.

I'm not completely set on this decision, but changing the behavior will require much deeper changes (essentially adding a test field to the Profile, which would have a big ripple effect).

I acknowledge that this is a bit of a wart in regards to retaining backwards compatibility, but I hope that it won't be too confusing, and can be addressed in the documentation to mention this special behavior.

[alexcrichton]

@rfcbot fcp merge

These changes all look good to me! I think the various warts/etc here are minor enough personally (and I can't think of better alternatives)

[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. 🔔

[joshtriplett]

As discussed in the @rust-lang/cargo meeting:

It sounds like cargo fix defaults to fixing all targets, including test code. So I don't think we need to treat that as a special-case, nor do we need to document it as one.

The cargo rustc behavior having several special cases for backwards compatibility doesn't seem like a concern to me; cargo rustc has always been an unusual command that requires care to use. So I don't have an issue just documenting those and letting them stand.

That just leaves cargo check. I believe cargo check should behave like cargo fix by default in this regard, and check test code in addition to other code. I don't know how hard this will be to change, but it seems like the right behavior, and it would eliminate this special case.

[ehuss]

Yea, the behavior of cargo check is a bit uncertain since I imagine most cases want the "check test" behavior. I'm just uncertain at this time what consequences that would have. I seem to recall some edge cases where that could cause problems (maybe that was just cfg(not(test)) stuff?). I think that's a big enough change that it would be worth considering that as a followup.

I'm going to go ahead and approve, and think about some of these edge cases more.

@bors r=alexcrichton

[bors]

📌 Commit 73dba76 has been approved by alexcrichton

[bors]

⌛ Testing commit 73dba76 with merge 4e143fd...

[bors]

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 4e143fd to master...