-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Use diff
crate while evaluating compile-fail
tests
#41474
Labels
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
nikomatsakis
added
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Apr 24, 2017
👍 |
Previously, we were dumping the differences between expected and actual compile-fail output like this
Now, it's something like this.
So, output-wise, no breaking/confusing changes introduced by this implementation change. |
bors
added a commit
that referenced
this issue
Apr 29, 2017
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.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
May 23, 2017
make ui test output patch compatible rust-lang#41948 Hello! Previously with rust-lang#41474 I've changed the internals of UI test output comparison mechanism. That change didn't change the diff format that we were producing but we needed to improve it anyway. This makes unified diff lines a little bit more `patch` compatible. Also I tried to introduce a unit test to check this but couldn't decide which of the following to implement: 1. Should I replace `println` macros with `Writer`s? And access the produced output within a test? 2. Should I add an external test (something like `src/test/run-pass/command-exec.rs`) 3. There are crates that capture `stdout`. Are they safe to use here? (I don't think so) Thanks! cc @nikomatsakis
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Hello,
Currently we're using some internal functionality for comparing
compile-fail
results.We should be using diff instead.
Thanks @nikomatsakis for suggesting this.
I'm working on this now.
The text was updated successfully, but these errors were encountered: