Update the mockall dev dependency to 0.13.0

[asomers]

This eliminates a duplicate dependency on syn

Motivation

Building mockall-0.11 required tokio to build both syn-1 and syn-2

Solution

Update the mockall dev dependency to the latest version.

[asomers]

I don't understand the miri error, even though I can reproduce it locally. It shouldn't be possible for Mockall itself to read uninitialized memory, because Mockall doesn't contain any unsafe code. This will need some more investigation...

[asomers]

I mostly understand the problem now. The uninitialized memory is coming from

tokio/tokio/src/io/blocking.rs

Line 251 in 0ec4d0d

let buf = unsafe { &mut *(buf as *mut [MaybeUninit<u8>] as *mut [u8]) };

. The failure happens because of a complicated interaction:

• std::io::Read::read, which specifies that implementors should not attempt to read from the provided buffer,
• tokio::io::blocking::Buf::read_from, which provides uninitialized memory to the blocking Read::read
• Mockall 0.12 and later, which attempt to use Debug::fmt on a mock method's arguments if the method's expectations aren't satisfied,
• The implementation of Debug on slice, which tries to debug every element
• Miri, which for some reason I don't understand is complaining about Mockall's use of Debug::fmt. I don't understand it, because since these tests don't fail Mockall should never be attempting to print the mock method's arguments.

I don't know why Miri cares about a method that never gets called.

[asomers]

Here's a more complete explanation: asomers/mockall#647

[Darksonn]

It is true that implementors of Read are allowed to read from the buffer and that this code triggers UB if that happens. However, in this case Tokio relies on the fact that std::fs::File does not read from the buffer, even if it could.

I guess in this case, the problem is that the type is not std::fs::File, and instead a mockall type that does not behave in the same way.

You can add

#[cfg(test)] 
buf.fill(0);

to silence this error.

[asomers]

@Darksonn this behavior will be fixed in the next release of Mockall. However, it will require Rust 1.77.0, which is too new for Tokio. So for now I've fixed the Miri failure by zero-initializing the buffer.

[Darksonn]

Thanks. Regarding the MSRV, we do not require dev-deps to be compatible with our MSRV.

[martin-g]

Why this workaround is applied only on &MockFile::read() but not on MockFile::read() above (https://github.com/tokio-rs/tokio/pull/7234/files#diff-66254466385396e6861c43b8488cbed96abb2bffae51f0b57dd9cad896c57edfR59) ?
Is it because MockFile::read() is not used in any tests and Miri does not detect the problem ?

[Darksonn]

That sounds right. I'm fine with adding it.

[martin-g]

IMO it would be better to update mockall to a newer version and remove this workaround. If an application test needs to assert the contents of the destination buffer then these (trailing?) 0s may lead to confusion

@asomers Does 0.13.1 fixes the issue with the early capturing of the method parameters ?
I could try myself after work!

[asomers]

@asomers Does 0.13.1 fixes the issue with the early capturing of the method parameters ?
I could try myself after work!

No it does not. But the next release of Mockall will.

[martin-g]

#7596 adds the workaround for MockFile too