New cfg key: `target_binary_format`

The proposal is to experimentally add a new cfg key to the language, target_binary_format (or similar, e.g. target_bin_fmt), for use by things like wasm32-none-component targets.

Code for such targets wants to cfg based on the object or binary format in use. Based on the current state of discussion about. the target maintainers don't feel comfortable forcing this information into target_env, as target_env does not contain this information for any other target.

This would also simplify certain existing cfg combinations that have to do annoying forms of reasoning to arrive at the answer to questions like e.g. "so, is this a PE32+ binary (whether executable or dll)?" The answer is unfortunately not as simple as "is this Windows?" due to the existence of e.g. target_os = "cygwin" and target_os = "uefi".

@rust-lang/lang Do I need a sponsor for this or something?

We have some of this information available in our target definitions, for reference. The proposal is to expose some already-known-to-the-compiler information, with some minor expansions on such as we will upgrade from only knowing about linkable intermediates to also knowing about linked binary formats: https://github.com/rust-lang/rust/blob/d7daac06d87e1252d10eaa44960164faac46beff/compiler/rustc_target/src/spec/mod.rs#L2370-L2371

• Sponsored by @joshtriplett^0

Object Format By Type and Loader/OS

Unresolved Questions

• Do we need both target_exe_format and target_dll_format? All major binary formats I'm aware of define both their executable and dynamic library formats as variations on the same object format, but "major" and "I'm aware of" are doing a lot of lifting there. It might be fine to simply say something like target_bin_format and add an additional key for target_dll_format later if we find an exception.
• Do we need a target_o_format? It seems unlikely to me personally (@workingjubilee), as while I wonder about the need to future proof against unexpected target variation, this primarily is about knowledge of the binary that code will actually execute in. However, as Amanieu noted^1, arguably it is "more principled" to reason based purely on object format.

See also

• https://github.com/rust-lang/compiler-team/issues/948

Start by reading the target-format information in compiler/rustc_target/src/spec/mod.rs around the referenced lines, then review compiler-team issue #948 and the linked discussion. The work is done when the cfg key design, including executable, dynamic-library, and object-format scope, is resolved and the compiler exposes the agreed target binary-format information.