cuviper / autocfg Goto Github PK
View Code? Open in Web Editor NEWAutomatic cfg for Rust compiler features
License: Apache License 2.0
Automatic cfg for Rust compiler features
License: Apache License 2.0
This assertion occasionally fails:
Lines 45 to 50 in c10bc17
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.
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:
Line 160 in c10bc17
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.
the newest version.
Program unwrap on an "Err" value, which causing a panic
Using auto-generated fuzz target can reproduce the behavior. it was uploaded to the issue platform.
unwrap_error.zip
actual: Panic happens, the program crashes.
expected: Handle unwrap without causing a panic.
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.
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
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]
.
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?
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
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.
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?
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.
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.
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.
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?
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.
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.
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)
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?
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?
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.
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.
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.
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.
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?
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
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
.
Ref: https://blog.rust-lang.org/2024/05/06/check-cfg.html
Each
cargo::rustc-cfg
should have an accompanying unconditionalcargo::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)
.
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.