cuviper / autocfg

Automatic cfg for Rust compiler features

autocfg

A Rust library for build scripts to automatically configure code based on compiler support. Code snippets are dynamically tested to see if the rustc will accept them, rather than hard-coding specific version support.

Usage

Add this to your Cargo.toml:

[build-dependencies]
autocfg = "1"

Then use it in your build.rs script to detect compiler features. For example, to test for 128-bit integer support, it might look like:

extern crate autocfg;

fn main() {
    let ac = autocfg::new();
    ac.emit_has_type("i128");

    // (optional) We don't need to rerun for anything external.
    autocfg::rerun_path("build.rs");
}

If the type test succeeds, this will write a cargo:rustc-cfg=has_i128 line for Cargo, which translates to Rust arguments --cfg has_i128. Then in the rest of your Rust code, you can add #[cfg(has_i128)] conditions on code that should only be used when the compiler supports it.

Release Notes

• 1.3.0 (2024-05-03)

  • Add probe_raw for direct control of the code that will be test-compiled.
  • Use wrappers when querying the rustc version information too.

• 1.2.0 (2024-03-25)

  • Add no_std and set_no_std to control the use of #![no_std] in probes.
  • Use RUSTC_WRAPPER and RUSTC_WORKSPACE_WRAPPER when they are set.

• 1.1.0 (2022-02-07)

  • Use CARGO_ENCODED_RUSTFLAGS when it is set.

• 1.0.1 (2020-08-20)

  • Apply RUSTFLAGS for more --target scenarios, by @adamreichold.

• 1.0.0 (2020-01-08)

  • 🎉 Release 1.0! 🎉 (no breaking changes)
  • Add probe_expression and emit_expression_cfg to test arbitrary expressions.
  • Add probe_constant and emit_constant_cfg to test arbitrary constant expressions.

• 0.1.7 (2019-10-20)

  • Apply RUSTFLAGS when probing $TARGET != $HOST, mainly for sysroot, by @roblabla.

• 0.1.6 (2019-08-19)

  • Add probe/emit_sysroot_crate, by @leo60228.

• 0.1.5 (2019-07-16)

  • Mask some warnings from newer rustc.

• 0.1.4 (2019-05-22)

  • Relax std/no_std probing to a warning instead of an error.
  • Improve rustc bootstrap compatibility.

• 0.1.3 (2019-05-21)

  • Auto-detects if #![no_std] is needed for the $TARGET.

• 0.1.2 (2019-01-16)

  • Add rerun_env(ENV) to print cargo:rerun-if-env-changed=ENV.
  • Add rerun_path(PATH) to print cargo:rerun-if-changed=PATH.

Minimum Rust version policy

This crate's minimum supported rustc version is 1.0.0. Compatibility is its entire reason for existence, so this crate will be extremely conservative about raising this requirement. If this is ever deemed necessary, it will be treated as a major breaking change for semver purposes.

License

This project is licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

autocfg's Issues

Expose `AutoCfg::probe`

Is there any particular reason why this is private?

Right now, I'm doing

cfg.emit_expression_cfg(r#"{
    #[non_exhaustive]
    struct Foo;
    Foo
}"#, "supports_non_exhaustive");

It would be nice to be able to check if #[non_exhaustive] struct Foo is supported without having to return a zero-sized type to make an expression.

Test if a dependency contains a path or symbol

Sorry if this is the wrong crate. This crate is the closest that I could find to the functionality that I need.

I'm porting code from C to rust that has #if defined(...) code.
The crate libc has the symbols I need but I can't find a way to automatically test if they actually exist (within cargo/rust) and do conditional compilation with that. Using '#[cfg(target_os = "...")]' combinations would be very error prone and a huge maintenance burden that I'm not gonna introduce.

What I need is something like this for build.rs:

let ac = autocfg::new();
// TODO some way to say that the test depends on the crate libc
ac.emit_path_cfg("libc::B76800", "has_libc_b76800");

Is it possible to use or adapt this crate for this use case?
If not, can you point me to any other crate that I can look into?

Support RUSTC_WRAPPER

In rust-num/num-complex#83, they reported problems detecting features under cargo no-std-check, which I found to be using RUSTC_WRAPPER to rewrite arguments for a fake target. This seems like something that autocfg could reasonably support. When present and non-empty, we would just wrap commands as $RUSTC_WRAPPER $RUSTC <args...>.

An alternate environment name is CARGO_BUILD_RUSTC_WRAPPER, or it can be set in .cargo/config -- but we don't have any support to find or parse config files yet.

Is there some way to hide the rustc output?

Hi,

Firefox's build and CI tooling parses the logs including verbose build script output to find and highlight errors. It helps a lot with quickly figuring out where build problems are, gets false positives from autocfg as it sees the rustc errors generated by attempts at determining if configurations build.

For example this:

 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u8
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u8
 INFO -  [crossbeam-epoch 0.8.0] cargo:rustc-cfg=has_min_const_fn
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u16
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u16
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u32
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u32
 INFO -       Running `/builds/worker/workspace/obj-build/release/build/crossbeam-utils-aca7e78e5e03b092/build-script-build`
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u64
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u64
ERROR -  [crossbeam-utils 0.8.1] error[E0412]: cannot find type `AtomicU128` in module `core::sync::atomic`
 INFO -  [crossbeam-utils 0.8.1]     --> <anon>:1:38
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1] 1    |   pub type Probe = core::sync::atomic::AtomicU128;
 INFO -  [crossbeam-utils 0.8.1]      |                                        ^^^^^^^^^^ help: a struct with a similar name exists: `AtomicU16`
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1]     ::: /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:2139:1
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1] 2139 | / atomic_int! {
 INFO -  [crossbeam-utils 0.8.1] 2140 | |     cfg(target_has_atomic = "16"),
 INFO -  [crossbeam-utils 0.8.1] 2141 | |     cfg(target_has_atomic_equal_alignment = "16"),
 INFO -  [crossbeam-utils 0.8.1] 2142 | |     stable(feature = "integer_atomics_stable", since = "1.34.0"),
 INFO -  [crossbeam-utils 0.8.1] ...    |
 INFO -  [crossbeam-utils 0.8.1] 2155 | |     u16 AtomicU16 ATOMIC_U16_INIT
 INFO -  [crossbeam-utils 0.8.1] 2156 | | }
 INFO -  [crossbeam-utils 0.8.1]      | |_- similarly named struct `AtomicU16` defined here
 INFO -  [crossbeam-utils 0.8.1]
ERROR -  [crossbeam-utils 0.8.1] error: aborting due to previous error
 INFO -  [crossbeam-utils 0.8.1]
 INFO -  [crossbeam-utils 0.8.1] For more information about this error, try `rustc --explain E0412`.

Gets picked up in a linux64 build and confuses the tooling.

Is there a way for autocfg to consume the output of rustc in a way that doesn't make it show up the logs of the build that calls into autocfg?

test suite unreliable since v1.2.0

Fedora package builds since v1.2.0 was released have been very unreliable. The test suite seems to fail in roughly 20% of test runs with various wild error messages, particularly from doctests:

   Doc-tests autocfg
     Running `/usr/bin/rustdoc --edition=2015 --crate-type lib --crate-name autocfg --test src/lib.rs --test-run-directory /builddir/build/BUILD/autocfg-1.3.0 -L dependency=/builddir/build/BUILD/autocfg-1.3.0/target/rpm/deps -L dependency=/builddir/build/BUILD/autocfg-1.3.0/target/rpm/deps --extern autocfg=/builddir/build/BUILD/autocfg-1.3.0/target/rpm/deps/libautocfg-0a1cc91a91fce621.rlib -C embed-bitcode=no --error-format human`
running 9 tests
test src/lib.rs - AutoCfg::probe_constant (line 450) ... ignored
test src/lib.rs - AutoCfg::probe_expression (line 432) ... ignored
test src/lib.rs - AutoCfg::probe_path (line 348) ... ignored
test src/lib.rs - AutoCfg::probe_sysroot_crate (line 329) ... ignored
test src/lib.rs - AutoCfg::probe_trait (line 376) ... ignored
test src/lib.rs - AutoCfg::probe_type (line 404) ... ignored
test src/lib.rs - (line 18) ... ok
test src/lib.rs - AutoCfg::probe_raw (line 291) ... FAILED
test src/lib.rs - AutoCfg::probe_raw (line 306) ... ok
failures:
---- src/lib.rs - AutoCfg::probe_raw (line 291) stdout ----
Test executable failed (exit status: 101).
stderr:
error: could not copy "target/probe1.probe1.a23b9cb2d7aa1a5f-cgu.0.rcgu.ll" to "target/probe1.ll": No such file or directory (os error 2)
error: aborting due to 1 previous error
thread 'main' panicked at src/lib.rs:7:1:
assertion failed: ac.probe_raw("#![no_builtins]").is_ok()
stack backtrace:
   0:     0x555a7d0debf2 - std::backtrace_rs::backtrace::libunwind::trace::h5f115adc35edca5e
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/../../backtrace/src/backtrace/libunwind.rs:105:5
   1:     0x555a7d0debf2 - std::backtrace_rs::backtrace::trace_unsynchronized::h66ac6b5395987b96
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x555a7d0debf2 - std::sys_common::backtrace::_print_fmt::h6baab85b78ec79f3
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/sys_common/backtrace.rs:68:5
   3:     0x555a7d0debf2 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8dd8d16e5e834e56
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x555a7d10089c - core::fmt::rt::Argument::fmt::h5821514b45bde58f
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/core/src/fmt/rt.rs:142:9
   5:     0x555a7d10089c - core::fmt::write::hd321594fe736ddf1
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/core/src/fmt/mod.rs:1153:17
   6:     0x555a7d0dc92f - std::io::Write::write_fmt::h752ef8cc7d69adde
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/io/mod.rs:1843:15
   7:     0x555a7d0de9c4 - std::sys_common::backtrace::_print::h0007831260368354
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x555a7d0de9c4 - std::sys_common::backtrace::print::h19e358810ed43c0a
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x555a7d0dfe7b - std::panicking::default_hook::{{closure}}::h149c09f4c91ac56c
  10:     0x555a7d0dfbd3 - std::panicking::default_hook::ha45b6f737d435c1e
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:292:9
  11:     0x555a7d0e031d - std::panicking::rust_panic_with_hook::haa066639b227c0f7
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:779:13
  12:     0x555a7d0e01b9 - std::panicking::begin_panic_handler::{{closure}}::h0bd6bf33af00b175
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:649:13
  13:     0x555a7d0df0c6 - std::sys_common::backtrace::__rust_end_short_backtrace::h1a5f92ec76439a12
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/sys_common/backtrace.rs:171:18
  14:     0x555a7d0dff24 - rust_begin_unwind
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:645:5
  15:     0x555a7d0ba0a5 - core::panicking::panic_fmt::h9d6211e5dc5960e4
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/core/src/panicking.rs:72:14
  16:     0x555a7d0ba163 - core::panicking::panic::h90be27f96fc60da6
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/core/src/panicking.rs:145:5
  17:     0x555a7d0bb74c - rust_out::main::_doctest_main_src_lib_rs_291_0::h2218db1b7c4606ce
  18:     0x555a7d0bb646 - rust_out::main::h3215e911437994eb
  19:     0x555a7d0bace3 - core::ops::function::FnOnce::call_once::hab37cc49c02b0940
  20:     0x555a7d0ba756 - std::sys_common::backtrace::__rust_begin_short_backtrace::h9c3ad854545ff677
  21:     0x555a7d0babc9 - std::rt::lang_start::{{closure}}::h7b78b3ddce1acd98
  22:     0x555a7d0d9ba3 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h09c601785505d569
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/core/src/ops/function.rs:284:13
  23:     0x555a7d0d9ba3 - std::panicking::try::do_call::hbfb70692164e52b9
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:552:40
  24:     0x555a7d0d9ba3 - std::panicking::try::hfb29355d55869458
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:516:19
  25:     0x555a7d0d9ba3 - std::panic::catch_unwind::h7ca6e679fd2bbbef
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panic.rs:146:14
  26:     0x555a7d0d9ba3 - std::rt::lang_start_internal::{{closure}}::hdf4dc303ca789fc0
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/rt.rs:148:48
  27:     0x555a7d0d9ba3 - std::panicking::try::do_call::heeb94d5f180f6e63
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:552:40
  28:     0x555a7d0d9ba3 - std::panicking::try::hf9ecce418a9a6dbf
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panicking.rs:516:19
  29:     0x555a7d0d9ba3 - std::panic::catch_unwind::hb943d40d7fe0efe6
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/panic.rs:146:14
  30:     0x555a7d0d9ba3 - std::rt::lang_start_internal::h2c0733911c428122
                               at /builddir/build/BUILD/rustc-1.78.0-src/library/std/src/rt.rs:148:20
  31:     0x555a7d0baba7 - std::rt::lang_start::h4af1243a7e175255
  32:     0x555a7d0bb795 - main
  33:     0x7f7c4bd9f1c8 - __libc_start_call_main
  34:     0x7f7c4bd9f28b - __libc_start_main_alias_1
  35:     0x555a7d0ba685 - _start
  36:                0x0 - <unknown>
failures:
    src/lib.rs - AutoCfg::probe_raw (line 291)
test result: FAILED. 2 passed; 1 failed; 6 ignored; 0 measured; 0 filtered out; finished in 0.38s
error: doctest failed, to rerun pass `--doc`
error: 1 target failed:
    `--doc`

I have seen failures like this now on x86_64, ppc64le, and s390x, so it does not appear to be architecture-specific, but more likely a race condition.

I can try running tests single-threaded if that helps?

error: could not compile `autocfg`

error: failed to build archive: function not supported

error: aborting due to previous error

error: could not compile autocfg

Caused by:
process didn't exit successfully: rustc --crate-name autocfg E:\Cargo\registry\src\github.com-1ecc6299db9ec823\autocfg-1.0.1\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off -C metadata=ed90b98a3f642806 -C extra-filename=-ed90b98a3f642806 --out-dir Z:\TEMP\cargo-installBt65NX\release\deps -L dependency=Z:\TEMP\cargo-installBt65NX\release\deps --cap-lints allow (exit code: 1)

autocfg does not work in the presence of -Z build-std

build.rs:

fn main() {
  assert!(autocfg::new().probe_sysroot_crate("std"));
}

cargo build works fine for any target where libstd is already distributed. cargo build --target x86_64-uwp-windows-msvc -Z build-std panics even though the sysroot is being built correctly.

Program unexpected panic when unwrap is used

version of autocfg

the newest version.

Bug description

Program unwrap on an "Err" value, which causing a panic

Steps to reproduce the behavior

Using auto-generated fuzz target can reproduce the behavior. it was uploaded to the issue platform.
unwrap_error.zip

actual behavior, and expected behavior.

actual: Panic happens, the program crashes.
expected: Handle unwrap without causing a panic.

'probe' does not work under Miri

When autocfg is used in the build script of a cargo miri test invocation, it recently stopped working.

It used to work because the RUSTC env variable was unset, and so autocfg bypassed Miri and queried the rustc binary, which usually is pretty much in sync with the miri binary that actually does all the building and running here, but there is no guarantee of that. It basically used to work by chance.

Since recently (to fix some other issues), RUSTC is now set to the miri binary. And now autocfg does not work any more. I don't quite know what fails yet -- looks like autocfg suppresses all rustc output, so I'll need to work with a patched autocfg to debug any of this (or if you have better ways of debugging autocfg that'd be great to know :). But it might be that the best way to fix this is to make autocfg aware of Miri and adjust its behavior.

Not compiling in Docker image running on M1 Mac using `--platform linux/amd64`

trying to compile a program that has a dependency on this package. It gets stuck trying to compile every time.

root@6e4aba89c52b:/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0# uname -a
Linux 6e4aba89c52b 5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022 x86_64 GNU/Linux
root@6e4aba89c52b:/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0# cargo build --verbose
   Compiling autocfg v1.1.0 (/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0)
     Running `rustc --crate-name autocfg src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=76b5da8da28534a1 -C extra-filename=-76b5da8da28534a1 --out-dir /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/deps -C incremental=/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/incremental -L dependency=/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/deps`
^C  Building [                             ] 0/1: autocfg
root@6e4aba89c52b:/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0# ls
Cargo.lock  Cargo.toml	Cargo.toml.orig  LICENSE-APACHE  LICENSE-MIT  README.md  examples  src	target	tests
root@6e4aba89c52b:/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0# cargo clean
root@6e4aba89c52b:/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0# cargo build --verbose
   Compiling autocfg v1.1.0 (/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0)
     Running `rustc --crate-name autocfg src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=76b5da8da28534a1 -C extra-filename=-76b5da8da28534a1 --out-dir /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/deps -C incremental=/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/incremental -L dependency=/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-1.1.0/target/debug/deps`
    Building [                             ] 0/1: autocfg

I've waited overnight. Still no love.

Docker command is

docker run --rm -ti --platform linux/amd64 -v $(pwd):/workspace rust:1 bash

M1 Mac - v12.5 (21G72)
Docker - v4.11.1 (84025)

Probing doesn't work for no-std targets

The probe command is using $RUSTC --target $TARGET, but if that target doesn't have std, all probes will fail to load the std prelude. We're going to need a way to add #![no_std].

ref: rust-num/num-traits#115

Probe const_fn

It would be sweet if it was possible to check not only if a certain path exists, but if it points to a const function. This looks like a significantly more involved check that those currently implemented, so perhaps it should exist just a recipe in the docs? See for an example: https://github.com/seanmonstar/unicase/pull/40/files/889d4761a67f7f61f950e98ab7f8ad5a60001039..39542760d0340195e4c5f14ed914d6ef1a3ca0f6#diff-a7b0a2dee0126cddf994326e705a91eaR12

crate has single crates.io owner

Hey, I've just noticed that this crate has only a single owner on crates.io. It might be a good idea to add a backup maintainer just in case.

Test for specific named feature in std?

Hello, thanks for the great library. I am wondering if it's possible to test for something like this feature https://doc.rust-lang.org/src/std/path.rs.html#2889

    #[stable(feature = "path_try_exists", since = "1.63.0")]

I can use the 1.63 version test, but I didn't know if there was a way to be a bit more specific for why I'm wanting that version.

Can I probe for const generics support?

I'd like to probe support for (minimal) const generics by checking this code:

type A<const N: usize> = [(); N];

But this can't be done with probe_type and I'm not sure how else to do it (other than maybe probe_rustc_version which seems kind of awkward). Any workarounds?

Fails to detect crate std on NixOS

Hi,

I've just ran into an issue with autocfg when trying to use zbus which depends on autocfg in my project. I'm developing on NixOS which has an bit of an unusual directory structure, which may lead autocfg astray. Which is why indexmap is led to belive it's being built in a nostd environment.

Is there any way to make autocfg belive that an certain crate is available or some other workaround?

Add a check for supporting `extern "x"` values

Rust currently has extern "C" and extern "Rust", but is likely to get more in the future - specifically C-unwind and crabi. A convenient way to probe for these would be helpful.

autocfg still calls rustc without the wrapper

I'm playing around with a patched version of cargo that lets me set

RUSTC_WRAPPER=<my binary here>
RUSTC=/path/that/does/not/exist

This makes it immediately obvious when something bypasses RUSTC_WRAPPER.

And it turns out this makes autocfg panic. I think it's this call that is not wrapped:

autocfg/src/lib.rs

Line 160 in c10bc17

let rustc_version = try!(Version::from_rustc(&rustc));

Consider adding `--cap-lints=warn` to probe `rustc` invocations

As mentioned in indexmap-rs/indexmap#144, the rust-server openapi-generator generates a local .cargo/config with -W missing_docs and -D warnings. This causes

warning: autocfg could not probe for `std`
error: missing documentation for the crate
 --> <anon>:1:1
  |
1 | extern crate std as probe;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `-D missing-docs` implied by `-D warnings`

error: aborting due to previous error

which causes indexmap to expose the wrong API and breaks the compilation of an older version of h2.

As far as I can tell, this is exactly what --cap-lints has been introduced to solve, so it might make sense to pass this flag to probe invocations of rustc.

Probing for nightly

Would it be a good idea to allow consumers of autocfg to probe if their compiler is nightly or not? This could be used in instances where a crate uses a nightly api, but it is not essential to the functioning of the crate. For example, a nightly-only api might make a function faster, or enable more functionality. Allowing probing if the compiler is nightly could allow a crate to automatically enable a "nightly" feature, so nightly users don't have to manually enable the feature. Alternatively crates that require nightly (like the popular rocket not so long ago) could give custom error messages with links to explanations of why they need nightly.

The argument against such an api is that it could be too magic and it could be bad for crater i.e. did nightly break the code or was the code always broken with the nightly feature enabled.

Publish 1.0

This seems to be a really great foundational crate with a rather narrow and well defined API. Maybe just publish 1.0, while there are relatively few users, to avoid upgrade pains?

Backport CARGO_ENCODED_RUSTFLAGS to version 0.1

Would it be possible to create a new 0.1 patch release with the CARGO_ENCODED_RUSTFLAGS behavior? Many crates can fail to build on cross-targets with the --locked cargo flag on newer rust versions because of the RUSTFLAGS change, noticed in the Void Linux CI: void-linux/void-packages#34889

Build errors on riscv64-linux

Host: BeagleV (beta), similar to the StarFive VisionFive 2
OS: 22.10 (Kinetic Kudu), fully updated (current kernel: Linux beaglev 5.17.0-1006-starfive)
Rust: version 1.64

Steps to replicate:

$ git clone https://github.com/cuviper/autocfg
$ cd autocfg
$ cargo build
   Compiling autocfg v1.1.0 (/home/tommy/projects/Rust/autocfg)
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc3d810)[0x3f8c964810]
linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x3f933fa800]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0x3cea1aa)[0x3f8fa111aa]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(_RNvCsZJaBwVYvUP_16rustc_query_impl15query_callbacks+0x916c)[0x3f8fc17baa]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0x94700a)[0x3f8c66e00a]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xd57d14)[0x3f8ca7ed14]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xcce018)[0x3f8c9f5018]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xcccb48)[0x3f8c9f3b48]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(_RNvMs0_NtCs2PGdSkTarcu_15rustc_interface7queriesNtB5_7Queries11global_ctxt+0x300)[0x3f8ca6d794]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xbecada)[0x3f8c913ada]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc387a6)[0x3f8c95f7a6]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xbed8d4)[0x3f8c9148d4]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc0a996)[0x3f8c931996]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc04666)[0x3f8c92b666]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc06da4)[0x3f8c92dda4]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc0b6da)[0x3f8c9326da]
/home/tommy/.rustup.riscv64-linux/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/libstd-f41102d4d21d2c30.so(rust_metadata_std_ac92b06979af539e+0xa0542)[0x3f8bc79542]
/lib/riscv64-linux-gnu/libc.so.6(+0x6a450)[0x3f8bb04450]
error: could not compile `autocfg`

Caused by:
  process didn't exit successfully: `rustc --crate-name autocfg src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=3c4f02795fa74efd -C extra-filename=-3c4f02795fa74efd --out-dir /home/tommy/projects/Rust/autocfg/target/debug/deps -C incremental=/home/tommy/projects/Rust/autocfg/target/debug/incremental -L dependency=/home/tommy/projects/Rust/autocfg/target/debug/deps` (signal: 11, SIGSEGV: invalid memory reference)

I got a bit closer with GDB:

Thread 2 "cargo" received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x3ff7e0ffc0 (LWP 1094)]
syscall (syscall_number=98, arg1=<optimized out>, arg2=137, arg3=0, arg4=0, arg5=0, arg6=-1, arg7=274609471544) at ../sysdeps/unix/sysv/linux/riscv/syscall.c:27
27	../sysdeps/unix/sysv/linux/riscv/syscall.c: No such file or directory.
(gdb) bt
#0  syscall (syscall_number=98, arg1=<optimized out>, arg2=137, arg3=0, arg4=0, arg5=0, arg6=-1, arg7=274609471544) at ../sysdeps/unix/sysv/linux/riscv/syscall.c:27
#1  0x0000002aab379664 in std::sys::unix::futex::futex_wait () at library/std/src/sys/unix/futex.rs:62
#2  0x0000002aab37c50e in std::sys::unix::locks::futex_condvar::Condvar::wait_optional_timeout () at library/std/src/sys/unix/locks/futex_condvar.rs:51
#3  std::sys::unix::locks::futex_condvar::Condvar::wait () at library/std/src/sys/unix/locks/futex_condvar.rs:35
#4  0x0000002aab3504d4 in <jobserver::HelperState>::for_each_request::<jobserver::imp::spawn_helper::{closure#1}::{closure#0}> ()
#5  0x0000002aab350a60 in std::sys_common::backtrace::__rust_begin_short_backtrace::<jobserver::imp::spawn_helper::{closure#1}, ()> ()
#6  0x0000002aab350cb2 in _RINvNvNtCseOBki07ryB6_3std9panicking3try7do_callINtNtNtCsidPuqEqzKzv_4core5panic11unwind_safe16AssertUnwindSafeNCNCINvMNtB6_6threadNtB1T_7Builder16spawn_unchecked_NCNvNtCsGjmX1GWYch_9jobserver3imp12spawn_helpers_0uEs_00EuEB2H_.llvm.3138756864971081497 ()
#7  0x0000002aab350d4e in __rust_try.llvm.3138756864971081497 ()
#8  0x0000002aab351954 in <<std::thread::Builder>::spawn_unchecked_<jobserver::imp::spawn_helper::{closure#1}, ()>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
#9  0x0000002aab37bdc0 in alloc::boxed::{impl#44}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1935
#10 alloc::boxed::{impl#44}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1935
#11 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#12 0x0000003ff7e7d450 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#13 0x0000003ff7ecaef2 in __thread_start () at ../sysdeps/unix/sysv/linux/riscv/clone.S:85

Seems like this might be a more fundamental bug, but I'm not sure how to proceed from here.

Add support for `--check-cfg` [Rust 1.80]

Ref: https://blog.rust-lang.org/2024/05/06/check-cfg.html

Each cargo::rustc-cfg should have an accompanying unconditional cargo::rustc-check-cfg directive to avoid warnings like this: unexpected cfg condition name: has_foo.

We probably want something like fn emit_check(cfg: &str) to pair with the current emit. Then each AutoCfg::emit_* method should call emit_check unconditionally, while their probe still guards their emit.

Maybe a combined helper is appropriate too, like fn emit_checked(cfg: &str, cond: bool).

hanging on aarch64

autocfg hangs / never finishes on aarch64 rust:

   Compiling autocfg v1.0.1 (autocfg)
    Finished test [unoptimized + debuginfo] target(s) in 3.85s
     Running unittests (target/debug/deps/autocfg-f01dc8476d25cc8c)

running 16 tests
test tests::dir_does_contain_target ... ok
test tests::dir_does_contain_target_with_custom_target_dir ... ok
test tests::dir_does_not_contain_target ... ok
test tests::dir_does_not_contain_target_with_custom_target_dir ... ok
test tests::version_cmp ... ok


test tests::autocfg_version has been running for over 60 seconds
test tests::probe_add has been running for over 60 seconds
test tests::probe_alloc has been running for over 60 seconds
test tests::probe_as_ref has been running for over 60 seconds
test tests::probe_bad_sysroot_crate has been running for over 60 seconds
test tests::probe_constant has been running for over 60 seconds
test tests::probe_expression has been running for over 60 seconds
test tests::probe_i128 has been running for over 60 seconds
test tests::probe_no_std has been running for over 60 seconds
test tests::probe_std has been running for over 60 seconds
test tests::probe_sum has been running for over 60 seconds

Add a method to control the `--edition`

If not specified, rustc defaults to the original 2015 edition. For many things it doesn't make much difference, but there could be new features that people want to probe that only work in newer editions. We could have something like:

impl AutoCfg {
    pub fn set_edition(&mut self, edition: Into<String>) { ... }
}

We may need to be careful about built-in probes though, to make sure they don't care about edition differences if possible.

Racy failures in `test_wrappers`

This assertion occasionally fails:

autocfg/tests/wrappers.rs

Lines 45 to 50 in c10bc17

	// Finally, make sure that `RUSTC_WRAPPER` is applied outermost
	// by using something that doesn't pass through at all.
	env::set_var("RUSTC_WRAPPER", "/bin/true");
	env::set_var("RUSTC_WORKSPACE_WRAPPER", "/bin/false");
	let ac = autocfg::AutoCfg::new().unwrap();
	assert!(ac.probe_type("mesize")); // anything goes!

I found that the probe sometimes gets an EPIPE when writing input to the child process. In this particular test scenario, the dummy /bin/true wrapper may exit too quickly, closing its stdin before we had a chance to write anything (which it wasn't going to look at anyway).

I don't think it's wrong for the library to consider that a failed probe, but I'd like to make the test more robust.

Doesn't work with custom Rust sysroot

This affects using autocfg in build setups that involve the new -Z build-std flag or xargo, both of which pass a --sysroot [something] flag when invoking rustc. The xargo case can be worked around by checking for RUSTFLAGS and passing them when probing using rustc, but I'm not sure what to do about build-std, since the sysroot doesn't appear to be exposed to build scripts at the moment.

rust-flags specified in cargo configs are ignored by autocfg.

When invoking rustc autocfg adds rustflags from the RUSTFLAGS environment variable. This makes things like setting --sysroot work.

The problem is flags can also be specified in the cargo configurations:
https://doc.rust-lang.org/cargo/reference/config.html

These do not seem to be picked up properly by autocfg, so some crates (indexmap in my case) cannot detect features properly if you set important flags like --sysroot in ~/.cargo/config or .cargo/config or any of the other paths used.