Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print better expectation messages on stable #425

Merged
merged 13 commits into from
Feb 9, 2023

Conversation

jefftt
Copy link
Contributor

@jefftt jefftt commented Nov 11, 2022

This change allows better messages for "No matching expectation found" on stable. This is a great user experience upgrade as it allows this behavior without requiring running with the nightly toolchain. This MR applies the generalized technique for autoderef specialization described here

@jefftt jefftt requested a review from asomers as a code owner November 11, 2022 19:56
@jefftt
Copy link
Contributor Author

jefftt commented Nov 11, 2022

Looks like it does regress on generic arguments though: tests/mock_generic_arguments.rs. Although it can work if there's a Debug trait bound on the generic

Copy link
Owner

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry it took me so long to review this. It's just been hard to find a solid block of time. I must say, this autoderef stuff is a big hack. But such a useful hack! It's so very useful, I don't think that Mockall can do without it. My biggest question is, "why bother with Display"? I think that Debug is more appropriate for this usage. If a type implements both, I think that Debug should get higher priority. And types that implement Display but not Debug are rarer than hens' teeth, so I don't think we should worry about them. Can we just eliminate the Display part?
Also, it needs a CHANGELOG entry.

let fstr = format!("{}({})", name, fields);
quote!(std::format!(#fstr, #(::mockall::MaybeDebugger(&#argnames)),*))
quote!(std::format!(#fstr, #((&&&::mockall::MaybeDebugger(&#argnames)).debug_string()),*))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

debug_string() will allocate space for a string and populate it. Then std::format! will do the same. That's less efficient than the original. Could we change the autoderef magic to create an actual Debug implementation like before, rather than use this debug_string method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

played around with this some more and got something that wont allocate unnecessarily!

mockall/tests/mock_generic_arguments.rs Show resolved Hide resolved
@jefftt
Copy link
Contributor Author

jefftt commented Nov 30, 2022

I must say, this autoderef stuff is a big hack. But such a useful hack! It's so very useful

I agree :) it's definitely an abuse of the type system, but very nice to not have to depend on nightly

My biggest question is, "why bother with Display"? I think that Debug is more appropriate for this usage. If a type implements both, I think that Debug should get higher priority. And types that implement Display but not Debug are rarer than hens' teeth, so I don't think we should worry about them. Can we just eliminate the Display part?

This was based on my very narrow use case of printing Date which, at the time, had a much better display implementation. Looks like they recently improved this so my point is now moot. time-rs/time#509. Removed the display trait

Copy link
Owner

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! Would you just mind rebasing to fix the conflict?

@jefftt
Copy link
Contributor Author

jefftt commented Jan 23, 2023

sorry for the late reply, i've rebased the branch on latest master

Copy link
Owner

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please resolve the Clippy error?

Copy link
Owner

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please either revert the pure-formatting changes, or else move them into a separate commit?

@jefftt
Copy link
Contributor Author

jefftt commented Feb 9, 2023

Could you please either revert the pure-formatting changes, or else move them into a separate commit?

ah sorry, i totally missed that...

@jefftt jefftt requested a review from asomers February 9, 2023 15:15
@asomers asomers merged commit 582640c into asomers:master Feb 9, 2023
@jefftt
Copy link
Contributor Author

jefftt commented Mar 29, 2023

@asomers hey sorry to bother you, but do you plan on including this in a release in the future? would like to use it in my projects without having to do a git override

@asomers
Copy link
Owner

asomers commented Mar 29, 2023

Yes, I will include it in the next feature release. I haven't published one yet because I'm still not completely happy with the concretize feature. See https://users.rust-lang.org/t/how-to-pass-multiple-items-to-a-derive-macro/91266 for more discussion about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants