Fallback to unknown vendor with vendored target triples

[zachreizner]

When a target triple is searched for, only exact matches with be
returned. This change will fallback to an "unknown" vendor in the
target triple if one with the specific vendor can not be found.

This helps with #41402.

[rust-highfive]

r? @matthewjasper

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

[zachreizner]

r? @japaric

[TimNN]

Ping from triage @japaric: This PR requires your review.

[zachreizner]

r? @dtolnay

David has volunteered to take a look at this.

[dtolnay]

I believe this would break anyone currently successfully using a non-unknown vendor with their own JSON target file. The code before would use their JSON file. The new code would prefer the corresponding builtin target with unknown vendor while ignoring their JSON file.

rust/src/librustc_target/spec/mod.rs

Lines 1101 to 1122 in cc4999e

	// check if triple is in list of supported targets
	if let Ok(t) = load_specific(target_triple) {
	return Ok(t)
	}
	// search for a file named `target_triple`.json in RUST_TARGET_PATH
	let path = {
	let mut target = target_triple.to_string();
	target.push_str(".json");
	PathBuf::from(target)
	};
	let target_path = env::var_os("RUST_TARGET_PATH").unwrap_or_default();
	// FIXME 16351: add a sane default search path?
	for dir in env::split_paths(&target_path) {
	let p = dir.join(&path);
	if p.is_file() {
	return load_file(&p);
	}
	}

I think the fallback to unknown would be more appropriate if applies only after an exact match JSON file has not been found.

[dtolnay]

I would write this as:

if triple.len() >= 3 && triple[1] != "unknown" {

[dtolnay]

Please add an explanation of what triple[1] represents and why this fallback makes sense. Right now it requires reading the PR description and linked issue to understand what is going on. For example just from the code it isn't clear why there wouldn't also be a fallback for triple[2] being unknown.

[dtolnay]

Please add a test. Possibly as simple as:

#[test]
fn test_load_specific() {
    let cros_target = load_specific("x86_64-cros-linux-gnu").unwrap();
    assert_eq!(cros_target.llvm_target, "x86_64-unknown-linux-gnu");
}

[TimNN]

Ping from triage @zachreizner: It looks like some changes have been requested to this PR.

[zachreizner]

I've been talking it over with an expert in the murky field of target triples and I'm not sure the solution I've started in this PR is the best way forward. It's a band-aid solution that isn't quite right, but happens to work. The proper solution would be to replicate the behavior from config.sub of the gnu config project. The approach there is to parse the target tuple, itself an organic accretion of decades of behavior, and then make intelligent choices based on os, vendor, arch, and abi. It is that latter half which would be hard to adapt to rustc's dictionary based approach to target configuration. It isn't possible to use a dictionary of target tuples in any intelligent fashion that doesn't look like band-aid solutions like in this PR. My disposition would be to abandon this PR as I don't have the time to refactor how rustc deals with target tuples, and it would seem rustc's maintainers are unlikely to accept such a refactor anyways.