When target_family is None, rustc sets it to unix.

[parched]

See

rust/src/librustc/session/config.rs

Lines 946 to 952 in ebeee0e

	let fam = if let Some(ref fam) = sess.target.target.options.target_family {
	Symbol::intern(fam)
	} else if sess.target.target.options.is_like_windows {
	Symbol::intern("windows")
	} else {
	Symbol::intern("unix")
	};

This is very unhelpful for bare-metal targets where there is no target family. Is there code that relies on it defaulting to unix if it is unspecified?

CC @arcnmx

[arcnmx]

All of the built-in librustc_back targets probably do, but that's easy to fix. The problem is that unix has always been the default, most custom user target specs probably rely on it (as the option was added more recently; a year ago is recent, right?). I'm certainly not a fan of there being any particular default. but I'm not sure that it can be changed if we want custom target specs to be backwards-compatible.

For embedded targets I'd suggest using a new target_family like "none" or whatever best describes the platform; that's why the option was added in the first place!

(see also #29551)

[parched]

Ok yes, changing it would break backwards compatibility. Although I wonder how many non unix target specs out there will break when they hit a crate with #[cfg(unix)] if we leave it as is (like happened to me with the rustc builtin *-none-eabi targets).

If we leave it as is, we should add target_family = "none" to the builtin *-none-eabi targets and also add a comment for target_family that it defaults to unix.

[parched]

Also related are os, vendor and env, currently you get the following

$ rustc --target=thumbv6m-none-eabi --print cfg
target_env=""
target_family="unix"
target_os="none"
target_vendor=""

they should consistently all be None of some form, whether that's "none" or "" I'm not sure.

CC @japaric

[japaric]

This should have been fixed (the target_family part) in #38401.

[parched]

OK, yes that is my preferred fix, but it will probably break some custom target specs as @arcnmx mentions.

[FenrirWolf]

I think a project of mine got hit by the fallout of this. Though what's more interesting is that manually setting the target_family field back to unix in my custom json spec doesn't seem to have any effect.

Edit: Scratch that. It helps to use the proper syntax in the config file!