Weid behavior on M1/ARM machines

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

Reproduce the report on an aarch64-apple-darwin environment by cloning tungstenite-rs and running the listed rustup, rustc, cargo clippy, build, and check commands. Compare Clippy's behavior with the other Cargo commands and inspect how the Rust 1.62.1 toolchain is selected for Clippy. Done means the target-dependent cause is identified and the issue has a verified resolution or a precise, actionable explanation.