custom target JSON fields do not error if they have an incorrect type

[Noratrieb]

If you have a custom target JSON with an incorrect type, for example "target-c-int-width": "16", the value will just be silently ignored instead of erroring.

this is because of the way the JSON parsing works:

rust/compiler/rustc_target/src/spec/json.rs

Lines 83 to 136 in 6caa224

	($key_name:ident = $json_name:expr, u64 as $int_ty:ty) => ( {
	let name = $json_name;
	if let Some(s) = obj.remove(name).and_then(|b| b.as_u64()) {
	base.$key_name = s as $int_ty;
	}
	} );
	($key_name:ident, bool) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(s) = obj.remove(&name).and_then(|b| b.as_bool()) {
	base.$key_name = s;
	}
	} );
	($key_name:ident = $json_name:expr, bool) => ( {
	let name = $json_name;
	if let Some(s) = obj.remove(name).and_then(|b| b.as_bool()) {
	base.$key_name = s;
	}
	} );
	($key_name:ident, u32) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(s) = obj.remove(&name).and_then(|b| b.as_u64()) {
	if s < 1 || s > 5 {
	return Err("Not a valid DWARF version number".into());
	}
	base.$key_name = s as u32;
	}
	} );
	($key_name:ident, Option<bool>) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(s) = obj.remove(&name).and_then(|b| b.as_bool()) {
	base.$key_name = Some(s);
	}
	} );
	($key_name:ident, Option<u64>) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(s) = obj.remove(&name).and_then(|b| b.as_u64()) {
	base.$key_name = Some(s);
	}
	} );
	($key_name:ident, Option<StaticCow<str>>) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(s) = obj.remove(&name).and_then(|b| Some(b.as_str()?.to_string())) {
	base.$key_name = Some(s.into());
	}
	} );
	($key_name:ident, Option<Align>) => ( {
	let name = (stringify!($key_name)).replace("_", "-");
	if let Some(b) = obj.remove(&name).and_then(|b| b.as_u64()) {
	match Align::from_bits(b) {
	Ok(align) => base.$key_name = Some(align),
	Err(e) => return Err(alignment_error(&name, e)),
	}
	}
	} );

It should be changed so that it emits an error.

[louwenus]

I would like to add to that the fact that the target.json compiler tests actually use these incorrect types (see rust/tests/run-make/target-specs/my-awesome-platform.json)

So, in parrallel of warning/erroring on bad format, it should be decided which format may be used.

I also encountered a weird error where both "crt-objects-fallback": "false", and "crt-objects-fallback": "true", led to the same behavior (no fallback), while removing the option completely led to the fallback

while trying to understand what are the crt option, (which are not documented, anywhere i could search for), i ran the following command:
rustc +nightly -Z unstable-options --print target-spec-json --target atmega32u4.json

to my surprise, the output json had some more option than the input, namely, crt-object-fallback, set to "false", that I did not set, and do change the behavior. (here is the file: atmega32u4.json)

All that to say that the json import/export both may have others problems. I would avoid them if it was possible unfortunately it seem that the crt option cannot be enabled back once deactivated in the json.

[Noratrieb]

The situation is even worse. Since all this is bespoke parsing, it is a large mess. Some fields do actually emit a nice error (like the link args). Some fields just ignore it. Some fields ignore it but emit warning (????). Some fields also just die because that is funny. Try "target-family": [0], a beautiful ICE.