Alan Somers
Alan Somers
I don't think so. AFAIK you still can't deprecate a trait impl https://github.com/rust-lang/rust/issues/39935 .
What about adding a feature flag to libc? An off-by-default "ifmib" feature would let crates like @ydirson's use the constants in their correct namespace, not conflicting with the new constant...
Whatever it's named, the default option should be the status quo, and the alternative would be to put ifmib into a submodule. BTW, I've seen other crates that call this...
Which helps if their crate's native error type is io::Error, but not other arbitrary error types. For example, in my case it's nix::Errno.
More fundamentally, mocking fields isn't even possible. How would you propose accessing the mock object's `elements` array?
I think it could be done. But just as you must for associated types. you'd have to tell automock what value of N to use.
I think your usage is basically correct, but there are a couple of small problems: * In your first `mock!` block, your `from` definition doesn't match the real struct. The...
No, syn is just fine. The main problem, as you observed, is that mockall generates some non-generic code for every mocked function. That means that multiple mock impls of the...
@ChriFo I fixed the problem with implementing the same trait multiple times on a generic struct. You should be able to just use plain `mock!` now, with no fancy hand-rolled...
Well, that's because `From` and `From` are different traits. PR #274 only solves the problem of implementing exactly the same trait twice. I think I'll fix that too, but in...