Weid behavior on M1/ARM machines

[daniel-abramov]

Summary

An attempt to run cargo clippy on a certain open-source repository triggers some non-obvious (weird) errors. I have never experienced such an issue before and am not sure what causes it, but it seems like other cargo tools (like build, test or check) don't exhibit such a behavior.

Basically, cargo clippy issues lots of errors like this:

error[E0514]: found crate `http` compiled by an incompatible version of rustc
   --> src/handshake/client.rs:263:35
    |
263 |         *response.version_mut() = http::Version::HTTP_11;
    |                                   ^^^^
    |
    = help: please recompile that crate using this compiler (rustc 1.64.0-nightly (4493a0f47 2022-08-02)) (consider running `cargo clean` first)
    = note: the following crate versions were found:
            crate `http` compiled by rustc 1.62.1: /Users/danielabramov/Development/Temporary/tungstenite-rs/target/debug/deps/libhttp-7678c1c40ba01260.rmeta

error[E0514]: found crate `rand` compiled by an incompatible version of rustc
   --> src/handshake/client.rs:273:23
    |
273 |     let r: [u8; 16] = rand::random();
    |                       ^^^^
    |
    = help: please recompile that crate using this compiler (rustc 1.64.0-nightly (4493a0f47 2022-08-02)) (consider running `cargo clean` first)
    = note: the following crate versions were found:
            crate `rand` compiled by rustc 1.62.1: /Users/danielabramov/Development/Temporary/tungstenite-rs/target/debug/deps/librand-150c29d9d94e1b71.rmeta

error[E0514]: found crate `base64` compiled by an incompatible version of rustc
   --> src/handshake/client.rs:274:5
    |
274 |     base64::encode(&r)
    |     ^^^^^^
    |
    = help: please recompile that crate using this compiler (rustc 1.64.0-nightly (4493a0f47 2022-08-02)) (consider running `cargo clean` first)
    = note: the following crate versions were found:
            crate `base64` compiled by rustc 1.62.1: /Users/danielabramov/Development/Temporary/tungstenite-rs/target/debug/deps/libbase64-211df52e54c0b018.rmeta

Note that the version of the compiler it suggests to use does actually match the version with which the crate was built, which confuses me.

The issue only happens on M1 Macbook so far and works fine on a regular Intel Macbook, so I wonder if it's a target-dependent issue.

Initiially I thought it's related to the compiler and has nothing to do with clippy, but cargo build and cargo check all work fine.

Apologies if I'm missing something and posted the issue to the wrong repository.

Reproducer

$ git clone git@github.com:snapview/tungstenite-rs.git

$ cd tungstenite-rs

$ rustup --version && rustc --version && cargo clippy --version
rustup 1.25.1 (2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.62.1 (e092d0b6b 2022-07-16)`
rustc 1.62.1
clippy 0.1.62 (e092d0b6 2022-07-16)

$ cargo clippy

Version

rustc 1.62.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: aarch64-apple-darwin
release: 1.62.1
LLVM version: 14.0.5

Additional Labels

No response

[xFrednet]

This sounds like a rustc problem, does the same thing happen with cargo check or is this Clippy specific?

[daniel-abramov]

I've tried cargo check, cargo build, cargo test (exectuing cargo clean in advance when needed), but they all worked fine (as described in the issue 😉), that's why I assumed that it might be related to clippy (my initial idea was that it's indeed something related to rustc, but I could not reproduce the issue with other cargo commands).

[xFrednet]

Sorry, I've only skimmed over that part. :sweat_smile: Hmm, so Clippy uses rustc internally so the problem probably arises from Clippy's usage of rustc which doesn't makes it hard to figure out where this comes from. Could you check to see if the problem remains in the current nightly version? :upside_down_face:

[daniel-abramov]

Sure.

I've tried installing nightly along with clippy and running it on nightly, but unfortunately the problem seem to persist.

Interesting enough, I can easily reproduce this issue with the aforementioned open-source repository, but not when I create a new empty repository. There must be something in tungstenite that confuses clippy I reckon 🤔 (and that "something" for some reason only happens on M1 Macbook, but not on regular Macbooks; not sure what it could be).

[xFrednet]

I've been thinking about this the last couple of days, but I sadly don't know how to approach this. I'm still sure that this is an issue in rustc or how Clippy interacts with the rustc API. But that's sadly it. I also don't have a M1 or Mac to investigate this :sweat_smile:. I think the best option would be to create an issue in rustc and describe the problem. It would be ideal if it could be narrowed down to less code than an entire repo

[daniel-abramov]

I'm still sure that this is an issue in rustc or how Clippy interacts with the rustc API.

Yeah, agree, this is quite likely I would say.

I think the best option would be to create an issue in rustc and describe the problem.

Sounds like an option, I've described the issue here: https://github.com/rust-lang/rust/issues/100329

[daniel-abramov]

UPD. I found a way simpler reproduction scenario. It looks like it's enough to have a dependency (external crate) used in a project in order to trigger the error.

Reproduction steps:

$ cargo new --bin clippy-test
$ cd clippy-test
$ cargo add tokio --features full

Then it's enough to just add something like this to main():

let (writer, reader) = tokio::io::duplex(5 * 1024);

And then run cargo check or cargo build that work fine, but an attempt to run cargo clippy results in:

$ cargo clippy
    Checking clippy-test v0.1.0 (/Users/danielabramov/Development/Temporary/clippy-test)
error[E0514]: found crate `tokio` compiled by an incompatible version of rustc
 --> src/main.rs:2:28
  |
2 |     let (writer, reader) = tokio::io::duplex(5 * 1024);
  |                            ^^^^^
  |
  = help: please recompile that crate using this compiler (rustc 1.62.1 (e092d0b6b 2022-07-16)) (consider running `cargo clean` first)
  = note: the following crate versions were found:
          crate `tokio` compiled by rustc 1.62.1: /Users/danielabramov/Development/Temporary/clippy-test/target/debug/deps/libtokio-3b6abcc35a3c838d.rmeta

[justinmoon]

When I uninstalled my global cargo-clippy in ~/.cargo/bin/ the problem went away.

[ghost]

This still seems to be an issue on M1 macs, I am using rustc 1.63

[ghost]

@application-developer-DA the problem seems to be with using cargo that was installed by brew. Make sure you are running cargo clippy using the cargo located at ~/.cargo/bin/cargo.

[AlecGhost]

I was able to fix the problem by removing all cargo packages installed via brew and running brew autoremove afterwards. That uninstalled /opt/homebrew/Cellar/rust/1.63.0..., which seemed to be the root of the problem.

[daniel-abramov]

Indeed, I've followed the suggestions that you guys mentioned and it works fine again. Basically I had to remove rustup (that I was installed with brew back then) and re-install it again with the "official" method (i.e. with curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh), after which the problem looks to be solved.

Not sure if I understand the root cause of it though 🙂