v0.35.12 Not Compiling on Stable

[rs017991]

When updating some dependencies, I noticed that as of v0.35.12 (tagged yesterday with no release notes), rustix fails to build with the stable toolchain.

error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /home/rs017991/.cargo/registry/src/github.com-1ecc6299db9ec823/rustix-0.35.12/src/lib.rs:99:26
   |
99 | #![cfg_attr(rustc_attrs, feature(rustc_attrs))]
   |                          ^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/rs017991/.cargo/registry/src/github.com-1ecc6299db9ec823/rustix-0.35.12/src/lib.rs:116:5
    |
116 |     feature(core_intrinsics)
    |     ^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/rs017991/.cargo/registry/src/github.com-1ecc6299db9ec823/rustix-0.35.12/src/lib.rs:116:13
    |
116 |     feature(core_intrinsics)
    |             ^^^^^^^^^^^^^^^

I attempted to track down the exact change that caused the issue, but I am rather new to Rust and am clearly missing something.

(the lines mentioned in the above errors have not changed recently)

[sunfishcode]

Hi! I'm not able to reproduce this, with rustc 1.64.0 (a55dd71d5 2022-09-19). Could you say what cargo features you've enabled, what Rust version you're using (eg. the output of rustc --version), and anything else that might be special about your build environment? Thanks!

[rs017991]

I am using rustc 1.64.0 (a55dd71d5 2022-09-19) as well, with the stable-x86_64-unknown-linux-gnu (default) toolchain.

I am not using rustix directly, but rather am inheriting it via:

$ cargo tree -i rustix -f "{p} {f}"
rustix v0.35.12 default,io-lifetimes,libc,std,termios,use-libc-auxv
└── terminal_size v0.2.1
    ├── clap v4.0.18 color,default,derive,error-context,help,std,suggestions,usage,wrap_help

[rs017991]

After messing around with it for a while trying (and failing) to reproduce the error with smaller programs, I tried building a freshly-cloned copy of the full program and it builds just fine.

So I'm guessing that there is something in the target directory that is corrupted or otherwise breaking things.

In case you think there might indeed be a rustix issue lurking about that you'd like diagnosed, I do still have a copy of the project that breaks every time. And I'm happy to run further experiments.

Or we can chalk it up to a ghost in the machine and I'll be on my way :)

Either way, sorry for the noise.

[ETKNeil]

After messing around with it for a while trying (and failing) to reproduce the error with smaller programs, I tried building a freshly-cloned copy of the full program and it builds just fine.

So I'm guessing that there is something in the target directory that is corrupted or otherwise breaking things.

In case you think there might indeed be a rustix issue lurking about that you'd like diagnosed, I do still have a copy of the project that breaks every time. And I'm happy to run further experiments.

Or we can chalk it up to a ghost in the machine and I'll be on my way :)

Either way, sorry for the noise.

One of the possibility is that you ran an old rust-analyzer (either by loading it into a jetbrains product or because you didn't update it), here is the PR that fix those issues : rust-lang/rust-analyzer#13010
The issue related : rust-lang/rust-analyzer#13019

And how it affect most user through thiserror : dtolnay/thiserror#192
I could be wrong tho, but this is usually why it happens.
A simple cargo clean then rebuild does the job !

[rs017991]

Thanks for the links. I do use IntelliJ, so that sounds likely. Let's call this closed.

[HU90m]

After messing around with it for a while trying (and failing) to reproduce the error with smaller programs, I tried building a freshly-cloned copy of the full program and it builds just fine.

So I'm guessing that there is something in the target directory that is corrupted or otherwise breaking things.

In case you think there might indeed be a rustix issue lurking about that you'd like diagnosed, I do still have a copy of the project that breaks every time. And I'm happy to run further experiments.

This saved me a lot of time; I had exactly the same issue and a simple rm -r target fixed it. Thanks for this!