-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Pretty print assertion failures in tests #79001
Conversation
e9024e7
to
22c575a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
Here are some first review comments:
src/test/ui/issues/issue-59488.rs
Outdated
@@ -31,4 +31,5 @@ fn main() { | |||
//~^ ERROR binary operation `==` cannot be applied to type `fn(usize) -> Foo {Foo::Bar}` [E0369] | |||
//~| ERROR `fn(usize) -> Foo {Foo::Bar}` doesn't implement `Debug` [E0277] | |||
//~| ERROR `fn(usize) -> Foo {Foo::Bar}` doesn't implement `Debug` [E0277] | |||
//~| ERROR `fn(usize) -> Foo {Foo::Bar}` doesn't implement `Debug` [E0277] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now duplciates an error. Can that be avoided?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. The expression is still used to create the same panic message as before, but now also used to form a &dyn Debug
in the AssertInfo
.
I'd be happy to avoid this if possible though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, maybe it can be done by using the same &dyn Debug
also for the panic message. Not sure if that is desirable though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I modified the macro to assign left_val
and right_val
to a &dyn Debug
once, and then use that for the rest of the code. The extra error is gone that way.
Interestingly, the compiler now only gives an error once per type. So if left and right are different types (and both don't implement Debug
), it gives an error for both. If they are the same type, only one error is generated. This seems like nice behaviour, so I added a UI test for it.
|
||
fn print_pretty_binary_assertion(assert: &BinaryAssertion<'_>) { | ||
eprintln!( | ||
"{bold}Assertion:{reset}\n {cyan}{left} {bold}{blue}{op}{reset} {yellow}{right}{reset}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the precedence of the comparison operator and any operators in the expressions on either side?
assert_eq!(true && false, false || true)
might give surprising results (especially if colors are not enabled).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point. Putting parenthesis around the expressions is possible, or it can be split further into separate lines for left
and right
.
I'll probably try out both to see how they look.
library/core/src/macros/mod.rs
Outdated
// The reborrows below are intentional. Without them, the stack slot for the | ||
// borrow is initialized even before the values are compared, leading to a | ||
// noticeable slow down. | ||
$crate::panicking::start_panic( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a new panicking function here means clippy will no longer recognize this panic. Once rust-lang/rust-clippy#6310 lands, this should be easy to fix by adding start_panic
to the list of panic functions it recognizes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was fixed in #79145, so you just need to update the functions clippy recognizes.
c590560
to
97d31d1
Compare
I tried to enhance I think we should do a perf run on this. |
Eep, if that was already bad I'm a little worried what this will do. I'm not sure how to do a perf run, but that sounds like a good idea. In the end I do think that increasing compile times is unavoidable for RFC 2011. Maybe it would be a solution to hide the new macro implementation behind |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit f56df5fdb6dc062411b4254f26989e7a1555b145 with merge c7bcb4ce327047165c733e403fbe3d345c7376a0... |
☀️ Try build successful - checks-actions |
Queued c7bcb4ce327047165c733e403fbe3d345c7376a0 with parent 8d2d001, future comparison URL. |
Finished benchmarking try commit (c7bcb4ce327047165c733e403fbe3d345c7376a0): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Ping again from triage: |
I'll try to resolve the conflicts. |
7fcdc68
to
ee2ae4a
Compare
☔ The latest upstream changes (presumably #90067) made this pull request unmergeable. Please resolve the merge conflicts. |
The assertion details are added as a new enum field, allowing for future extensions with different information for other sources of panics. For example, `.unwrap()` could extend the enum to store a `&dyn Error` in the panic info. The panic handler in `std` passes the additional info unmodified to the panic hook.
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
And use a comma to separate arguments of `assert_eq` and `assert_ne`. This has two advantages: * The printed text more closely matches the actual source code. * It avoids changing the meaning of $left == $right if $left or $right contain operators themselves.
`GetConsoleMode` was declared twice with different signatures. The signatures have contained different definitions of `HANDLE`.
ee2ae4a
to
e0279b3
Compare
☔ The latest upstream changes (presumably #90273) made this pull request unmergeable. Please resolve the merge conflicts. |
It seems that the current conflict cannot be resolved by simple rebasing. The problem is the ongoing constification of panic_fmt. master:
feature branch:
I think it would be necessary to make both functions const and change the const-eval hook. But it would be better to wait until the other work on panic_fmt has been completed. @de-vri-es @m-ou-se |
Ping from triage:
Seems like this PR has stalled. What would you like to do? |
Closing this pr due to inactivity. Thanks for taking the time to contribute. |
This PR aims to allow the test framework to pretty-print assertion failures with colors and a more readable format than the current panic messages. It is meant to work towards #44838 (without actually modifying
assert!()
itself at this point).The PR adds a new
extra_info
field toPanicInfo
. Currently,extra_info
is an enum that can only contain&AssertInfo
, but it is meant to be extendable with different variants in the future. It could potentially be used to record details for other sources of panics too. The panic handler instd
ensures that theextra_info
is also passed to the panic hook unmodified.I also looked into passing the
AssertInfo
as panic payload rather than a new field onPanicInfo
. However, casting an&AssertInfo
to&dyn Any
would requireAssertInfo: 'static
, but it borrows the evaluated expressions.The PR adds an new unstable
--pretty-print-assertions
flag to test binaries to enable the pretty printing. When used, the test runner installs a panic hook that does the pretty-printing. The printing is done withprint!()/println!()
to ensure the output is still captured by the test framework. That means that the color codes need to be included in theprint!()
calls, which is only possible with terminals that support ANSI color codes. Support for ANSI color codes is checked before enabling them.For now, the PR only modifies
assert_eq!()
andassert_ne!()
, since they're much easier. Next up would beassert!()
parsing the input expression and generating the properAssertInfo
for the panic.And now some pictures!
Without pretty-printing:
The pretty printing is hidden behind an unstable command line flag to allow more time to tweak the format, and of course to actually implement expression parsing in
assert!()
.I imagine there is a lot of bike-shedding potential on the exact output format. Initially I wanted to go with the format used by
assert2
, but I figured that might be too opinionated.r? @m-ou-se