use diff crate for compile-fail test diagnostics #41474 #41588
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Could we see a before/after comparison of a failure? Unless they're the same. |
shepmaster
added
the
S-waiting-on-review
|
The code looks good to me. @cengizio, do you have a handy "before/after" comparison to show @Mark-Simulacrum? @Mark-Simulacrum -- for context, this only affects the diffs that print when a ui test fails. The older code was using a "hand-rolled" diff algorithm that really didn't cope well with new lines being inserted etc. This code now uses the standard "diff" algorithm, so I would expect the printouts to look much easier to read. |
|
@bors r+ |
|
📌 Commit 837817c has been approved by |
|
Hello @Mark-Simulacrum! Thanks for keeping an eye on the issue. Is this sample good enough for you? Please let me know if it's not. I'd be happy to provide full samples for each case. |
use diff crate for compile-fail test diagnostics #41474 Hello! This fixes #41474 We were using a custom implementation to dump the differences between expected and actual outputs of compile-fail tests. I removed this internal implementation and added `diff` crate as a new dependency to `compile-fail`. Again, huge thanks to @nikomatsakis for guiding.
|
Yep, that's good enough for me. Just wanted to see an overall view. Thanks! |
Mark-Simulacrum
added
S-waiting-on-bors
|
☀️ Test successful - status-appveyor, status-travis |
Hello!
This fixes #41474
We were using a custom implementation to dump the differences between expected and actual outputs of compile-fail tests.
I removed this internal implementation and added
diffcrate as a new dependency tocompile-fail.Again, huge thanks to @nikomatsakis for guiding.