Fix suggestions for x.py setup

[alarsyo]

#76631 introduced a new setup command to x.py

By default the command prompts for a profile to use:

Welcome to the Rust project! What do you want to do with x.py?
a) Contribute to the standard library
b) Contribute to the compiler
c) Contribute to the compiler, and also modify LLVM or codegen
d) Install Rust from source

and then displays command suggestions, depending on which profile was chosen. However the mapping between chosen profile and suggestion isn't exact, leading to suggestions not being shown if the user presses c or d. (because "c" is translated to "llvm" and "d" to "maintainer", but suggestions trigger for "codegen" and "user" respectively)

A more thorough refactor would stop using "strings-as-type" to make sure this kind of error doesn't happen, but it may be overkill for that kind of "script" program?

Tagging the setup command author: @jyn514

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

r? @jyn514

[jyn514]

A more thorough refactor would stop using "strings-as-type" to make sure this kind of error doesn't happen, but it may be overkill for that kind of "script" program?

That seems like it would be useful, yeah. I thought of doing it in the original PR but never got around to it. Maybe something like this?

enum Profile {
  Compiler,
  Codegen,
  Library,
  User,
}

// keeps case-insensitive matching, etc.
impl FromStr for Profile { ... }
impl Display for Profile { ... }
impl Profile {
  fn include_path(&self, src_path: &Path) -> PathBuf
}

[jyn514]

@alarsyo are you still interested in making the more general change I mentioned in #77400 (comment)? No problem if not, this is good to merge as-is.

[alarsyo]

I am! Pushing a patch soon

[alarsyo]

I'm not happy with having the a, b, c, d letters from the prompt as part of the FromStr implementation, maybe having a match like this

match choice_string {
    "a" => Profile::Library,
    "b" => Profile::Compiler,
    "c" => Profile::Codegen,
    "d" => Profile::User,
    other => match other.parse() {
        Ok(profile) => profile,
        Err(prof_err) => { print error, continue;}
    }
}

in the prompting function would be better

[jyn514]

I don't think it's a big deal either way. I kind of like it the way it is since it means there's only one place the match has to be exhaustive, but you could convince me it would be easier to keep a/b/c in sync if it's next to the prompt.

[alarsyo]

You're right, having only one match to keep exhaustive might be best :)

[jyn514]

This already looks a lot better :)

[jyn514]

I don't think it's a big deal either way. I kind of like it the way it is since it means there's only one place the match has to be exhaustive, but you could convince me it would be easier to keep a/b/c in sync if it's next to the prompt.

[jyn514]

@bors r+

Thanks for working on this!

[bors]

📌 Commit c09cf00d782bc16e795bf278eb67ee017240cbe6 has been approved by jyn514

[bors]

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[alarsyo]

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[jyn514]

@bors r+

[bors]

📌 Commit d67a7e6 has been approved by jyn514