Skip to content
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

Warning: mocked function never used #410

Closed
mlthlschr opened this issue Sep 24, 2022 · 13 comments
Closed

Warning: mocked function never used #410

mlthlschr opened this issue Sep 24, 2022 · 13 comments
Labels
question Usage question

Comments

@mlthlschr
Copy link

Hi,

since I updated my rust version on build I receive the warning that several of the mocked functions are never used, such as

...

warning: associated function `expect_count_items` is never used
  --> src/db/items.rs:32:14
   |
32 |     async fn count_items(&self) -> Result<i64, anyhow::Error>;
   |     

warning: associated function `expect` is never used
  --> src/db/items.rs:18:1
   |
18 | #[automock]
   | ^^^^^^^^^^^

...

Is there a way to fix/suppress that warning?

@asomers
Copy link
Owner

asomers commented Sep 24, 2022

What compiler version do you have, and how is your struct or trait defined? The warnings probably wouldn't be emitted if the trait were pub. Also, you probably want to use #[cfg_attr(test, automock)], unless you actually want to ship the mocks in your finished library.

@mlthlschr
Copy link
Author

mlthlschr commented Sep 25, 2022

I use rustc 1.64.0 (a55dd71d5 2022-09-19).

The struct is defined like that:

#[async_trait]
#[automock]
pub(crate) trait Queries: Sync + Send {
    async fn count_items(&self) -> Result<i64, anyhow::Error>;
    // some more functions
    // the ones which are actually not used in tests are having a warning
}

Using #[cfg_attr(test, automock)] instead of #[automock] actually fixed the problem compiler-wise. The warning is only there when running tests. Also, rust_analyzer is still showing the warning in the editor.

@asomers
Copy link
Owner

asomers commented Sep 25, 2022

So you're still seeing warnings for the expect_* methods? I think it would make sense for Mockall to suppress those.

@mlthlschr
Copy link
Author

mlthlschr commented Sep 26, 2022

Yeah, exactly. After changing to #[cfg_attr(test,automock)] the warnings disappeared for builds and checks, but when running tests they are still there. That's not such a big problem anymore.

Every expect_* function I do not use in the tests is having a warning when running the tests.

@krojew
Copy link

krojew commented Sep 27, 2022

Can confirm - expect_* functions trigger the dead_code warning.

@asomers
Copy link
Owner

asomers commented Sep 27, 2022

You need to put #[automock] before #[async_trait]. I'm actually surprised that it compiled at all. You probably would've run into bigger problems if you'd actually tried to set any expectations.
https://docs.rs/mockall/latest/mockall/#async-traits

@asomers asomers added the question Usage question label Sep 27, 2022
@rharish101
Copy link

rharish101 commented Nov 26, 2022

How about an attr for methods that makes automock skip generating mocked versions? It should look like this:

#[automock]
trait MyTrait {
    fn foo(&self) -> u32;
    #[nomock]
    fn bar(&self, x: u32, y: u32) -> u32;
}

This way, MockMyTrait will only have expect_foo generated, not expect_bar. This should suppress warnings that expect_bar isn't used.

The only other way of suppressing those warnings is to use mock! and manually write down the functions you want to mock, which can be inconvenient.

@asomers
Copy link
Owner

asomers commented Nov 27, 2022

@rharish101 the problem should be fixed by using automock and async_trait in the correct order. Or are you still seeing this warning?

@rharish101
Copy link

rharish101 commented Nov 27, 2022

Yes, I tried both positions. automock raises the warnings if it's moved before async_trait, and I face compilation errors in the other case.

@asomers
Copy link
Owner

asomers commented Nov 27, 2022

@rharish101 you aren't the OP, so I assume that your code is different. Would you please post it, along with your unwanted warnings?

@rharish101
Copy link

rharish101 commented Nov 27, 2022

Here's a sample project with the following structure:

.
├── Cargo.lock
├── Cargo.toml
└── src
    ├── foo.rs
    └── main.rs

1 directory, 4 files

Cargo.toml:

[package]
name = "dummy"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dev-dependencies]
mockall = "0.11.3"

src/main.rs:

mod foo;

fn main() {
    println!("Hello, world!");
}

src/foo.rs:

#[cfg(test)]
use mockall::automock;

#[cfg_attr(test, automock)]
pub trait MyTrait<T> {
    fn foo(&self, x: T);
}

When simplifying my code into this dummy example, I noticed that the warnings are only raised (with cargo check --tests) if all the following happen:

  • MyTrait is defined in a separate file (here foo.rs) that is loaded in main.rs. Storing it directly in main.rs didn't raise warnings.
  • The type parameter T is needed. Changing MyTrait to not use type params and substituting T with u32 didn't raise warnings.

Note that async-trait isn't used anywhere, since I can reproduce the warnings reliably without it.

Also, I didn't actually write a test that uses MockMyTrait, but you can still reproduce the warnings if you add a bar method to MyTrait and just use MockMyTrait::expect_foo in the test.

@asomers
Copy link
Owner

asomers commented Nov 27, 2022

@rharish101 I can reproduce this problem only using Rust 1.64.0 and 1.65.0,, but not 1.63.0, 1.66.0-beta.2 (0040709e3 2022-11-20), or 1.67.0-nightly (b7bc90fea 2022-11-21). So I assume it's related to a compiler bug. Also, your problem is most definitely not related to the OP's, so I'm going to close the issue. Feel free to open a new one if you continue to have problems with compilers other than 1.64.0 and 1.65.0.

@asomers asomers closed this as completed Nov 27, 2022
@guiyomh
Copy link

guiyomh commented Dec 12, 2022

Me too, I reproduce the problem with rust 1.65.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Usage question
Projects
None yet
Development

No branches or pull requests

5 participants