The best strategy for Mockall consumers is to use the #[allow(dead_code)]
just like you did. Or else, you know, to bug Mockall's maintainer to
release the patch ;)
On Fri, Oct 14, 2022, 2:59 PM Thomas Weißschuh <thomas(a)t-8ch.de> wrote:
On 2022-10-14 21:54+0100, Richard W.M. Jones wrote:
> On Fri, Oct 14, 2022 at 10:42:30PM +0200, Thomas Weißschuh wrote:
> > rustc 1.64.0 generates warnings for the mocked Server.
> > This leads to a failure of test.sh.
> >
> > ```
> > warning: associated function `expect` is never used
> > --> tests/common/mod.rs:49:1
> > |
> > 49 | / mock!{
> > 50 | | pub Server {}
> > 51 | | impl Server for Server {
> > 52 | | fn cache(&self, count: u32, offset: u64) ->
Result<()>;
> > ... |
> > 86 | | }
> > 87 | | }
> > | |_^
> > |
> > = note: `#[warn(dead_code)]` on by default
> > ```
> > ---
> >
> > Note: This also affects the maintenance branches.
> >
> > plugins/rust/tests/common/mod.rs | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/plugins/rust/tests/common/mod.rs
b/plugins/rust/tests/common/mod.rs
> > index 61c30464..de26c89f 100644
> > --- a/plugins/rust/tests/common/mod.rs
> > +++ b/plugins/rust/tests/common/mod.rs
> > @@ -48,6 +48,7 @@ lazy_static! {
> >
> > mock!{
> > pub Server {}
> > + #[allow(dead_code)]
> > impl Server for Server {
> > fn cache(&self, count: u32, offset: u64) -> Result<()>;
> > fn can_cache(&self) -> Result<CacheFlags>;
> >
> > base-commit: 20c2dc98b6bbde2f92e63d500d5e6015184bb105
>
> Yes this has been bugging me as well, and probably we should put this
> patch upstream.
>
> However I will note that Alan submitted an issue about the underlying
> issue:
>
>
https://listman.redhat.com/archives/libguestfs/2022-September/030074.html
>
https://github.com/asomers/mockall/issues/414
>
> It's marked as fixed, but for some reason that didn't seem to fix the
> tests - I'm still seeing the unused 'expect' here, even after
> completely deleting the cargo cache.
I think the fixed version of mockall is just not released yet.
What is your guidance for packagers?
Especially as this is also affecting the 1.32 branch.
For now I am carrying the patch from the parent mail downstream.
Thomas