cackle-rs / cackle

A code ACL checker for Rust
Other
206 stars 7 forks source link

Build failure for rustix-0.37.27 #16

Closed jayvdb closed 3 months ago

jayvdb commented 3 months ago

My project builds correctly, and has several versions of rustix in our Cargo.lock, but with cargo-acl & using rust 1.80 it fails at rustix-0.37.27 with:

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/jayvdb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.37.27/src/lib.rs:101:26
    |
101 | #![cfg_attr(rustc_attrs, feature(rustc_attrs))]
    |                          ^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/jayvdb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.37.27/src/lib.rs:117:5
    |
117 |     feature(core_intrinsics)
    |     ^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/jayvdb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.37.27/src/lib.rs:117:13
    |
117 |     feature(core_intrinsics)
    |             ^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `rustix` (lib) due to 3 previous errors
warning: build failed, waiting for other jobs to finish...

Error: `cargo` exited with non-zero exit status

The code in question is at https://github.com/bytecodealliance/rustix/blob/v0.37.27/src/lib.rs#L101

During cargo-acl, I get the following problems before it crashes with the above

`rustix[0.38.34]` uses the `fs` API in its build script
`rustix[0.38.34]` uses the `process` API in its build script                                                                                                          ┃
`rustix[0.37.27]` uses the `process` API in its build script                                                                                                          ┃
`rustix[0.37.27]` uses the `fs` API in its build script
...
`rustix[0.38.34]` uses unsafe                                                                                                                                         ┃
`rustix[0.38.34]` uses unsafe

My cackle.toml already contains the following, so I assume that cargo-acl has already gotten one version of rustix working on my project.

[pkg.rustix]
allow_unsafe = true
build.allow_apis = [
    "fs",
    "process",
]

My cackle.toml common secton only contains version = 2

jayvdb commented 3 months ago

I did a little digging into why I have rustix-0.37.27 in my dep tree, and it comes in because async-std hasnt had a release in two years ( https://github.com/async-rs/async-std/issues/1081 ) .

Is there any way to skip cargo-acl analysis of this crate version?

davidlattimore commented 3 months ago

I had a quick try to reproduce by creating a simple crate that depends on rustix. So far I haven't been able to. Based on the errors, I'd guess that maybe rustix's build script is getting confused and activating configurations that are only supposed to be used on nightly. That's just a guess though.

Some bits of information that might be useful for me to help reproduce this:

davidlattimore commented 3 months ago

Is there any way to skip cargo-acl analysis of this crate version?

Unfortunately there isn't. Cackle runs cargo build on your project and instruments the build so as to analyse each build artifact. So skipping things isn't really an option, because then the thing wouldn't be built and the rest of the build would fail.

Ah, so you're not depending on rustix directly. I'll have a look and see if I can reproduce via a dependency on async-std.

davidlattimore commented 3 months ago

Good news. I managed to reproduce the problem :)

jayvdb commented 3 months ago

The top level source of this problem is httpmock

rustix v0.37.27
└── async-io v1.13.0
    ├── async-process v1.8.1
    │   └── async-std v1.12.0
    │       ├── async-object-pool v0.1.4
    │       │   └── httpmock
    ...
    │       └── httpmock v0.7.0 (*)
    └── async-std v1.12.0 (*)

I have other rustix in my Cargo.lock , and cargo-acl seems to able to process them.

Im using rustup ; have no rust-toolchain.toml, Linux, etc

davidlattimore commented 3 months ago

It looks like it only reproduces if I don't enable sandboxing of build scripts. i.e. this triggers the bug:

[sandbox]
kind = "Disabled"

This builds fine:

[sandbox]
kind = "Bubblewrap"

So if it's an option to install bubblewrap, then that would at least give you a workaround until I can figure out and fix the bug. Sandboxing of build scripts is nice to have anyway :)

jayvdb commented 3 months ago

Confirming that workaround. Thanks.