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.