Currently we run the `rustc` from the `RUSTC` environment variable to
figure out whether or not to enable `f16` and `f128`, based on the
`target_has_reliable_{f16,f128}` config. However, this does not know
about the codegen backend used, and the backend isn't trivial to check
in a build script (usually it gets set via `RUSTFLAGS`).
It turns out we don't actually need to run `rustc` here: Cargo
unconditionally emits all config from the relevant compiler as
`CARGO_CFG_*` variables, regardless of whether or not they are known
options. Switch to checking these for setting config rather than
invoking `rustc`.
As an added advantage, this will work with target.json files without any
special handling.
Fixes: ed17b95715dd ("Use the compiler to determine whether or not to enable `f16` and `f128`")
The `rustc` probe done in our build scripts needs to pass `--target` to
get the correct configuration, which usually comes from the `TARGET`
environment variable. However, for targets specified via a `target.json`
file, `TARGET` gets set to the file name without an extension or path.
`rustc` will check a search path to attempt to locate the file, but this
is likely to fail since the directory where Cargo invokes build scripts
(and hence where those scripts invoke `rustc`) might not have any
relation to the JSON spec file.
Resolve this for now by leaving `f16` and `f128` disabled if the `rustc`
command fails. Result of the discussion at CARGO-14208 may eventually
provide a better solution.
A CI test is also added since custom JSON files are an edge case that
could fail in other ways. I verified this fails without the fix here.
The JSON file is the output for `thumbv7em-none-eabi`, just renamed so
`rustc` doesn't identify it.
Currently we whether or not to build and test `f16` and `f128` support
mostly based on the target triple. This isn't always accurate, however,
since support also varies by backend and the backend version.
Since recently, `rustc` is aware of this with the unstable config option
`target_has_reliable_{f16,f128}`, which better represents when the types
are actually expected to be available and usable. Switch our
compiler-builtins and libm configuration to use this by probing `rustc`
for the target's settings.
A few small `cfg` fixes are needed with this.
