Cargo metadata: Expose available build profiles

[jschwe]

Problem

Currently cargo metadata does not expose which custom build profiles are available.
For corrosion which integrates cargo into CMake it would be nice to expose a list of available build profiles for users to choose from (e.g. in a graphical interface for configuring CMake cache variables).

Proposed Solution

Add an additional field to the package section which contains an array of available profile names (dev, release, test, bench plus any custom profiles).

Notes

No response

[jyn514]

This would be helpful for holmgr/cargo-sweep#76.

[calavera]

I was looking to extract profile information from cargo metadata, when I noticed that the information in not serialized, and I bumped into this issue.

I maintain a Cargo plugin called Cargo Lambda to help people build and deploy Rust projects on AWS Lambda. By default, Cargo Lambda adds some release optimizations, via RUSTFLAGS, when projects are built, like -C strip="symbols. Small binaries are important to deploy on AWS Lambda because they help reduce cold starts. Debug symbols are also not useful on AWS Lambda because you cannot attach a debugger to your production environment. This way, people don't need to add optimizations to every project themselves.

I was about to add other optimizations, and I wanted to check if the user has already set those options in their [profile.release] section. This check is important because I don't want to override values set by users. For example, I want to set -C lto="thin" by default, but if a user has set [profile.release] lto="fat", I don't want to override the option. My idea was to check the profile information from cargo metadata and apply optimizations as needed. Without exposing the profiles data, I have to parse Cargo.toml files myself.

I can update the code and open a PR to expose the profile data if this issue is accepted. I've contributed to the project in the past, so I'm familiar with the codebase.

[ehuss]

Unrelated to this issue, I would advise against using -C flags to override cargo's behavior. There are some rules that cargo uses that can be disrupted or broken if you try to override them manually. If you want to control a profile setting, I would suggest to use environment variables (or maybe --config), like CARGO_PROFILE_RELEASE_LTO=thin or CARGO_PROFILE_RELEASE_STRIP=symbols.
(That won't help with your use case to not override the user's setting, since config takes precedence.)