Support for custom Cargo profiles, #2

[da-x]

This allows creating custom profiles that inherit from other profiles.

For example, one can have a release-lto profile that looks like this:

[profile.custom.release-lto]
inherits = "release"
lto = true

The profile name will also carry itself into the output directory name
so that the different build outputs can be cached independently from
one another.

So in effect, at the target directory, a name will be created for
the new profile, in addition to the 'debug' and 'release' builds:

    $ cargo build --profile release-lto
    $ ls -l target
    debug release release-lto

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[da-x]

This is my working version for supporting custom profiles in Cargo, implementing #2007 . It is revamps from 10 months ago for the current version of Cargo. My previous PR was #5326 .

I saw that "workflows" are still unstable, and people are asking for a custom profile solution. For instance - tikv/tikv#4189 . The previous PR was more complete in terms of coverage over the various Cargo commands, documentation and more, and I can revamp that as well if needed.

[bors]

☔ The latest upstream changes (presumably #6687) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Thanks for the PR! I've flagged this to be discussed during our weekly meeting later today.

[alexcrichton]

Hey sorry for the late reply, but we did indeed discuss this last week and the conclusion is that we're not quite ready to merge this yet. While this has had some design discussion we felt that there's still enough open questions that we'd prefer for a design discussion ahead of a PR. This is a large enough feature that we felt and RFC was an appropriate venue for designing this in particular.

Thanks regardless for the PR though! I'm gonna go ahead and close this but if you've got any questions don't hesitate to ask

[da-x]

Internals forum Pre-RFC.