"#![feature] may not be used on the stable release channel"

[lfrancke]

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/lars/.cargo/registry/src/github.com-1ecc6299db9ec823/thiserror-1.0.35/src/lib.rs:211:34
    |
211 | #![cfg_attr(provide_any, feature(provide_any))]
    |                                  ^^^^^^^^^^^

This works in 1.0.34 and before.
I tried this on an otherwise totally empty project. Happy to share more details. The docs don't mention that a nightly version is required so I assume this was unintentional?

➜  ~ rustc --version
rustc 1.63.0 (4b91a6ea7 2022-08-08)

[dtolnay]

I am not able to reproduce this.

$ cargo tree
testing v0.0.0
└── thiserror v1.0.35
    └── thiserror-impl v1.0.35 (proc-macro)
        ├── proc-macro2 v1.0.43
        │   └── unicode-ident v1.0.3
        ├── quote v1.0.21
        │   └── proc-macro2 v1.0.43 (*)
        └── syn v1.0.99
            ├── proc-macro2 v1.0.43 (*)
            ├── quote v1.0.21 (*)
            └── unicode-ident v1.0.3

$ cargo +stable check
   Compiling proc-macro2 v1.0.43
   Compiling quote v1.0.21
   Compiling unicode-ident v1.0.3
   Compiling syn v1.0.99
   Compiling thiserror v1.0.35
   Compiling thiserror-impl v1.0.35
    Checking testing v0.0.0
    Finished dev [unoptimized + debuginfo] target(s) in 4.47s

$ rustc +stable --version
rustc 1.63.0 (4b91a6ea7 2022-08-08)

[lfrancke]

That is very weird. I just left the computer but will try again tomorrow. This was a fresh "cargo new --lib" project with thiserror as the only dependency and no code.

[dtolnay]

Okay. I'll close for now but we can reopen if you or anyone else is able to provide repro steps.

[lfrancke]

Okay. I created a new project this morning and I can't replicate it either.
But my old project from yesterday still showed the same behavior. I did a dff and they were exactly the same.
A cargo clean helped fix the "old" project. So, there must have been something cached somewhere from old compile runs.
Because I did encounter this error and then removed things from the project until I was back at an empty project.

I have to admit that I didn't expect that behavior of cargo.
Sorry for the noise and thanks for your help.

[dtolnay]

If you are using an old rust-analyzer or intellij-rust, try upgrading because buggy past versions of those can screw up the target directory in ways similar to this.

[lfrancke]

Thanks for the hint. I am using intellij-rust but it's the very latest version. So, there might still be a bug there.

[fishseabowl]

I have the same problem. But cargo clean helps with that.

[TheDudeFromCI]

I was able to reproduce this issue. And yes, I am using rust-analyzer on VSCode, if that makes a difference.

It seems to be caused by using this lib on one project that uses a Nightly build, then switching to a project that uses a Stable build. Running Cargo clean does fix the issue.

[VictorKoenders]

This seems to be an issue in build.rs with detecting if thiserror is able to compile with nightly features.

On this line the build script checks for the RUSTC_WRAPPER environment variable. However the rust-analyzer plugin in vscode overrides this value to be something else:

This setting is enabled by default, and my guess is that it returns a successful status code when thiserror feeds in the code which has a nightly-only feature flag enabled. Because thiserror sees that the executed program returns a successful status code, it automatically enables other nightly features, breaking rust-analyzer.

A temporary workaround is to pin the thiserror version to 1.0.34, to before this check was introduced.

[dtolnay]

If there is a rust-analyzer bug, please report it to https://github.com/rust-lang/rust-analyzer.

[VictorKoenders]

To me it seems like thiserror incorrectly assumes it's being ran in an environment that accepts nightly feature flags

[dtolnay]

What in thiserror assumes that?

[VictorKoenders]

As per my previous comment:

This seems to be an issue in build.rs with detecting if thiserror is able to compile with nightly features.

On this line the build script checks for the RUSTC_WRAPPER environment variable. However the rust-analyzer plugin in vscode overrides this value to be something else:

This setting is enabled by default, and my guess is that it returns a successful status code when thiserror feeds in the code which has a nightly-only feature flag enabled. Because thiserror sees that the executed program returns a successful status code, it automatically enables other nightly features, breaking rust-analyzer.

A temporary workaround is to pin the thiserror version to 1.0.34, to before this check was introduced.

[dtolnay]

That is literally the opposite of assuming though, right? It checks whether the toolchain supports nightly flags.

If rust-analyzer randomly enables or does not enable nightly flags during the course of the same build, that would be a rust-analyzer bug.

[VictorKoenders]

Is there a definition on what the status code is that the RUSTC_WRAPPER binary should return? I'm not sure if this is well-defined, and something that should be relied on

[dtolnay]

Rust-analyzer's RUSTC_WRAPPER exit code is the same as the underlying rustc command exit code so I don't expect that would be the issue in this case. See https://github.com/rust-lang/rust-analyzer/blob/ee2d9eddb6f31773a507c918553214cb816a0abe/crates/rust-analyzer/src/bin/rustc_wrapper.rs#L50.

[dtolnay]

At this point I feel like we're just keeping the "I use 4-month-old rust-analyzer (or intellij) because I enjoy hitting bugs that were already fixed in those projects 3 months ago" crowd entertained, so I'll lock this issue from further discussion at this point.