Change:
use std::fs; use std::path::PathBuf; use std::process::Command; <ins> use walkdir::WalkDir; </ins> use crate::builder::Kind; use crate::core::config::Target;

Discussion:
I ran twice with slight different typos in the argument. Unfortunately, this takes about half an hour to detect (stage2, LLVM builds) and changing the host seems to invalidate some of the build. Bootstrap can't actually query for the target list, but it would be great if it could verify the triple string exists somewhere in as a sanity check before kicking off a multistage build. label +T-bootstrap +E-easy -needs-triage
label -needs-triage
The target may only exist in the compiler that will be built, so bootstrap would need to parse for this check rather than asking the bootstrap compiler. And I think it also needs to allow json target specs.
What would be the right place to detect this, i.e, to disallow initiating the build at the beginning itself if the or triple is invalid?
Other sanity checks are done in
I believe the checks are being done here: Although, I am not quite sure about ? Since there are limited number of targets, do we just create some constant structure to store this and just map if it does not have any typos?
I think you found the correct locations for such a check. takes a flag that doesn't build anything. These checks should run even on dry run, so don't worry about that. You could probably just use regex to extract a target list from the file linked in , then add a check that the specified hosts and targets all exist in that list.
This approach is too straightforward; custom targets will fail from this logic.
Do we have custom target info available early? If not, even a warning that something isn't in the list would be helpful here
We do. can be a good ref to this. ~Also, I don't think reading list from the compiler source file will be a good idea. Why not using someting like ? That can give the built-in target list for the stage 0 compiler.~ EDIT: I just saw , ignore my suggestion here.
I see this function: Do we just use this for the search part?
That is a 10 year old commit...
When you say custom targets did you mean when we have some architecture (say arm_64) with certain properties differing from the standard definition (like target-endian, linker, etc.)? Ref:
You can indeed do such stuff, but I wouldn't restrict the purpose of "custom-targets" with that.

There is this documentation if you want to read more about it.
As you mentioned, the regex approach wouldn't cover the custom targets that are made by the user in json format, so I currently see tests for this here: Could you elaborate the custom target approach, I mean the only thing we have to check if the json file exists at the mentioned user path and whether each of the attributes under it are valid? For the default targets we just check in the static file as mentioned earlier.
For custom targets I would avoid checking if the attributes are valid. Validating them is a lot more complicated and can give false positives too when an attribute is newly introduced and not available in the bootstrap compiler yet.
The logic for validating the target name can be as follows: First, check if the target exists in the built-in target list. If not, check if it's a custom target (by verifying if a target specification JSON file was provided). If none of the above returns true, then either the user forgot to provide the target specification JSON file for the custom target or made a typo in the target name.