cuviper / autocfg Goto Github PK

View Code? Open in Web Editor NEW

92.0 92.0 24.0 94 KB

Automatic cfg for Rust compiler features

License: Apache License 2.0

Rust 99.16% Shell 0.84%

autocfg's People

Contributors

Stargazers

Watchers

autocfg's Issues

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)

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)

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

'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.

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?

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.

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?

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?

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

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.

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

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.

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.

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));

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.

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.

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.

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.

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?

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.

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.

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

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.

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?

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.

	// 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!