-
-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.0.53 interacts badly with sccache: feature may not be used on the stable release channel #278
Comments
I was not able to reproduce this with those same commands. $ rustc -vV
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: aarch64-apple-darwin
release: 1.75.0
LLVM version: 17.0.6
$ cargo new --lib thiserr-test
Created library `thiserr-test` package
$ cd thiserr-test
$ cargo add thiserror
Updating crates.io index
Adding thiserror v1.0.53 to dependencies.
Updating crates.io index
$ cargo build
Compiling proc-macro2 v1.0.73
Compiling unicode-ident v1.0.12
Compiling thiserror v1.0.53
Compiling quote v1.0.34
Compiling syn v2.0.44
Compiling thiserror-impl v1.0.53
Compiling thiserr-test v0.1.0
Finished dev [unoptimized + debuginfo] target(s) in 2.27s |
Would you be able to share the relevant environment variables from your shell where this issue occurs? $ env | grep 'RUST\|CARGO' Another thing that might reveal what is going on would be the contents of cargo config.toml. $ RUSTC_BOOTSTRAP=1 cargo -Zunstable-options config get |
With Scripter17/url-cleaner@f4b3988 on Rust 1.75, compiling a debug build will fail but not in release mode. The commands you recommended provided nothing relevant except that I'm using Weirdly, removing that from my global cargo config makes the error not happen??? I have no idea what that could possibly mean but it also fixed something with tokio (tokio-macros?) from having errors linking to libc. So uh, @m-spitfire, if you use sccache try clearing the cache? |
Thank you @Scripter17! Connecting this to sccache is very helpful. I published one possible fix in thiserror 1.0.54 and another possible fix in 1.0.55. Would you be willing to try both of them to see whether this issue still occurs in either one? I would love if you could wipe the sccache cache in between trying the 2 fixes, but if that would be too disruptive then don't worry about it and I am still interested in the result. |
I wiped the sccache cache and recompiled with the same version. It seems to have fixed it If needed I'll try getting the broken cache from a backup and compile with that |
According to my hypothesis in #279, one way you might be able to deterministically screw up the cache is: $ cargo update -p thiserror --precise 1.0.53
$ RUSTC_BOOTSTRAP=1 cargo +stable check
$ cargo clean
$ unset RUSTC_BOOTSTRAP
$ cargo +stable check # FAIL If this reproduces the bug with 1.0.53 and not with 1.0.54 and/or 1.0.55, then I think we'd be set. Thank you! |
Oh, that might not do it on its own. 🙁 There might also have needed to be some Cargo settings changed in between the first Let me install sccache myself and try to experiment with this. |
I was able to find a deterministic repro: #!/bin/bash
set -e
set -x
sccache --stop-server || true
rm -rf repro ~/.cache/sccache
unset RUSTC_BOOTSTRAP
cargo +stable new repro
cd repro
mkdir .cargo
echo -e "[build]\nrustc-wrapper = \"$HOME/.cargo/bin/sccache\"" > .cargo/config.toml
cargo +stable add thiserror@=1.0.53
cargo +stable update -p syn --precise 2.0.43
cargo +stable update -p quote --precise 1.0.33
cargo +stable update -p proc-macro2 --precise 1.0.71
RUSTC_BOOTSTRAP=1 cargo +stable check
cargo +stable build # FAIL This reproduces the bug in thiserror 1.0.53 and succeeds with 1.0.54 and 1.0.55 (so the second change #280 is not needed after all, only #279). I'll close this as fixed but we can reopen if anyone still hits anything like this with thiserror 1.0.54+. |
To reproduce
Change version to
=1.0.52
.Now
cargo build
works fine.I checked that the CI for 1.0.53 has ran fine yesterday, so this might be an issue with OS (unlikely tho)?
The text was updated successfully, but these errors were encountered: