You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If one uses assert_eq! or assert_ne! macros inside closures defined inside a #[test_case(...)], the drop-in replacement method provided by the pretty_assertions won't work, as the compilation fails on ambiguous resolution of those from use super::* here and the ::std provided one.
The solution would be to simply add a feature-guarded use ::pretty_assertions::{assert_eq, assert_ne} after the line above. Would not need test_case to depend on pretty_assertions even.
Would you accept a PR for that?
The text was updated successfully, but these errors were encountered:
Hi. Sorry that took so much time to answer, but I wanted to think about the issue and also review possible solutions. I'm not fond of adding a dependency or feature related to particular crates within test-case.
I'm looking for something inbetween, where'd you define per-crate replacement for assert_eq and assert_ne macros, but I need to see how viable it is first. Will come back to you once I have a PoC, but if you have an opinion already, then it's most welcome.
Hoi,
If one uses
assert_eq!
orassert_ne!
macros inside closures defined inside a#[test_case(...)]
, the drop-in replacement method provided by the pretty_assertions won't work, as the compilation fails on ambiguous resolution of those fromuse super::*
here and the::std
provided one.The solution would be to simply add a feature-guarded
use ::pretty_assertions::{assert_eq, assert_ne}
after the line above. Would not needtest_case
to depend onpretty_assertions
even.Would you accept a PR for that?
The text was updated successfully, but these errors were encountered: