feat(complete): Added completion for --profile

[Gmin2]

What does this PR try to resolve?

This attempts to complete the autocompleter for cargo build --profile <TAB>, it loads the built in profiles and the custom profile present in Cargo.toml and .cargo/config.toml if present when pressing TAB key, in the completion value it also adds an description inspired by this

Related to #14520

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

This is also profile in configuration file, though we might not want to go that far in completion code I guess?

cargo/src/cargo/core/profiles.rs

Lines 1299 to 1302 in 611b7c4

	/// Helper for fetching a profile from config.
	fn get_config_profile(ws: &Workspace<'_>, name: &str) -> CargoResult<Option<TomlProfile>> {
	let profile: Option<context::Value<TomlProfile>> =
	ws.gctx().get(&format!("profile.{}", name))?;

[epage]

In the main flow, I believe we do load [profile] from both config and workspace because we do Profile::new().get_profile_names which looked like the main code path for doing this.

This code path is for when that fails. We could try to make it smarter and give people as much information as can successfully run but that ends up duplicating a lot more of Profiles. My assumption is that it will be fine with the hard coded list.

[epage]

Could you clean up the commits for how they should be merged?

[epage]

btw the CI failure is being tracked in rust-lang/rust#138863

[Gmin2]

Could you clean up the commits for how they should be merged?

Done

[weihanglo]

Unnecessary allocation

Suggested change

	clap_complete::CompletionCandidate::new("dev".to_string())
	clap_complete::CompletionCandidate::new("dev")

[epage]

FYI it will allocate either way; its just not needed to be explicit (and I prefer limiting to_string() to only when doing conversions)

[weihanglo]

We are recreating Profiles struct here, which doesn't really make sense, as Profiles already has every profile. But for completion, this seems acceptable?

BTW we could use let-else so one less identation level.

Suggested change

	if let Ok(profile_instance) = Profiles::new(&ws, name) {
	let Ok(profile_instance) = Profiles::new(&ws, name) else {
	continue;
	};

[Gmin2]

BTW we could use let-else so one less identation level.

done

We are recreating Profiles struct here, which doesn't really make sense, as Profiles already has every profile. But for completion, this seems acceptable?

you are right that recreating the Profiles struct for each profile name is inefficient, the original profiles object should already contain all the information, I kept this approach for consistency with the existing implementation, but if you think it would be better to refactor this to avoid the redundant Profiles creation i would be happy to refactor it

[epage]

Thanks for your work on this!