Discrepancy between local test and GitHub action

help
1

Why the discrepancy? I can't get the error to show up locally, so I must be running clippy incorrectly.

Local:

❯ RUSTFLAGS=-Dwarnings cargo clippy --tests -- -Dclippy::all -Dclippy::pedantic
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s

GitHub:

ci.yaml

env:
  CARGO_TERM_COLOR: always
  RUSTFLAGS: -Dwarnings

jobs:
  clippy:
    name: Clippy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@clippy
      - run: cargo clippy --tests -- -Dclippy::all -Dclippy::pedantic

error: the item `String` is imported redundantly
 --> src/xml.rs:2:5
  |
2 | use std::string::String;
  |     ^^^^^^^^^^^^^^^^^^^
 --> /rustc/3b1717c052de4a2dbdd3badb0e7a885f40a8ad9e/library/std/src/prelude/mod.rs:125:13
  |
  = note: the item `String` is already defined here
  |
  = note: `-D unused-imports` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(unused_imports)]`

error: could not compile `tazb` (bin "tazb" test) due to 1 previous error
Error: Process completed with exit code 101.
2

Are you using different Rust versions? Clippy adds new lints with each version of Rust, so it might be that code which passes on one compiler will start to fail when using a newer compiler (or vice versa).

3 Likes
3

The toolchain versions of your local computer and your CI must differ. Note that

uses the latest nightly release. If you instead wish to run your CI with the latest stable Rust release, I'd try replacing the line with the following:

- uses: dtolnay/rust-toolchain@stable
  with:
    components: clippy
2 Likes
4

So how do I get the error to show up locally then? This didn't work:

~/dev/ao/tazb on  main [!]
❯ rustup update
info: syncing channel updates for 'stable-aarch64-apple-darwin'
info: syncing channel updates for 'nightly-aarch64-apple-darwin'
info: checking for self-update

   stable-aarch64-apple-darwin unchanged - rustc 1.76.0 (07dca489a 2024-02-04)
  nightly-aarch64-apple-darwin unchanged - rustc 1.78.0-nightly (3b1717c05 2024-03-10)

info: cleaning up downloads & tmp directories

~/dev/ao/tazb on  main [!]
❯ RUSTFLAGS=-Dwarnings cargo +nightly clippy --tests -- -Dclippy::all -Dclippy::pedantic
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s

Still no error.

5

Re-reading your error message I just realized it is actually a rustc lint—unused_imports—that causes the error, not a clippy lint. Are you building your project locally with a different feature set, perhaps?

Edit: I replicated the warning on the playground:

use std::string::String;

fn main() {
    let _ = String::from("hello");
}

If you run clippy, it will give you a warning because String is imported twice, once in the prelude and once explicitly with the use statement. As to why the lint isn't showing locally on your machine, I don't know.

Edit 2: Shows locally on my machine as well. I'm on x86_64-unknonw-linux-gnu, I wonder if it doesn't work on your apple platform somehow?

6

What is meant with "a different feature set"? Basically, the only things I've added to Cargo.toml is deps and Clap stuff. There is no lint configuration in the source.

You say it's a rustc lint. Is there another way to trigger it? Afaik cargo clippy uses those, too, correct?

Maybe someone else on aarch64 will chime in, I don't know.

Really appreciate the help.

7

I thought maybe your package has features and your local build uses a different set of them than your CI.

Yes, cargo +nightly check and therefore all other build commands like build, run, test, etc. should trigger it.

Could you try running the example code I posted above with nightly on your machine in a new package? Then we know for sure if this is an issue with your package or your toolchain.

8

Okay, this is getting more annoying. :slight_smile:

When I cargo +nightly check your snippet, it triggers the warning.

Out of desperation, I did a cargo clean and then cargo +nightly check in my project, and lo and behold, the warning shows up. I now have no idea why it didn't happen, and I can't get it to compile without the warning anymore.

Anyway, thanks for your help, as at least I'm getting the same result now (but no way to check why).

1 Like
9

The build cache likes to keep its mysteries :man_shrugging: :smile:

2 Likes
10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.