Uh oh!
There was an error while loading. Please reload this page.
Enable blessing of mir opt tests - #69916
Conversation
rust-highfive
commented
Mar 11, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
RalfJung
commented
Mar 13, 2020
Is there an example of how a "function allocation" would print? I couldn't find one. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
bors
commented
Mar 25, 2020
📌 Commit d7053261c6b1a5531e4e5a1423cba832e891b98a has been approved by |
rust-highfive
commented
Mar 25, 2020
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
eddyb
commented
Mar 25, 2020
@bors r- rustfmt |
bors
commented
Mar 25, 2020
☔ The latest upstream changes (presumably #70404) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
commented
Mar 26, 2020
@bors r=eddyb |
bors
commented
Mar 26, 2020
📌 Commit 178d8a4d426e265e14daf463e8b7f2652d3231b7 has been approved by |
oli-obk
commented
Mar 26, 2020
@bors r=eddyb somehow my local rustfmt isn't working reliably anymore :( |
bors
commented
Mar 26, 2020
📌 Commit c9a5a03 has been approved by |
bors
commented
Mar 27, 2020
bors
commented
Mar 27, 2020
☀️ Test successful - checks-azure |
| for line in result.lines { | ||
| match line { | ||
| DiffLine::Expected(e) => { | ||
| println!("-\t{}", e); |
There was a problem hiding this comment.
Okay this is weird, but apparently println! in compiletest is not equivalent to writing to std::io::stdout(), what's happening now is that the diff is printed while the tests run, and then the output after the tests run looks like this:
diff of stderr:
The actual stderr differed from the expected stderr.
There was a problem hiding this comment.
Looking at the implementation it seems like there should be no difference unless something is calling set_print -- I think libtest does this, though, so maybe that's causing problems here.
There was a problem hiding this comment.
Ahh, compiletest is getting that behavior from libtest, that's what I was missing, thanks!
Yeah so worst case we can buffer into a String and println! that instead of using std::io::stdout.
There was a problem hiding this comment.
Turns out the changes here are unnecessary, there's only write_diff caller, and I've just tested a fix, will open a PR shortly.
EDIT: opened #70662.
…k-Simulacrum compiletest: don't use `std::io::stdout()`, as it bypasses `set_print`. This PR undoes a change made during rust-lang#69916, which became unnecessary during review but was left in by accident, and which isn't correct due to `libtest` using `std::io::set_print`, which overwrites the `println!` behavior but *not* `writeln!(std::io::stdout(), ...)`. The effect of using `writeln!(std::io::stdout(), ...)` was that the diff output would show *while* running the tests, instead of at the end, when failing tests are listed. r? @Mark-Simulacrum cc @oli-obk
…k-Simulacrum compiletest: don't use `std::io::stdout()`, as it bypasses `set_print`. This PR undoes a change made during rust-lang#69916, which became unnecessary during review but was left in by accident, and which isn't correct due to `libtest` using `std::io::set_print`, which overwrites the `println!` behavior but *not* `writeln!(std::io::stdout(), ...)`. The effect of using `writeln!(std::io::stdout(), ...)` was that the diff output would show *while* running the tests, instead of at the end, when failing tests are listed. r? @Mark-Simulacrum cc @oli-obk
…crum ci: run mir-opt tests on PR CI also as 32-bit (for `EMIT_MIR_FOR_EACH_BIT_WIDTH`). Background: rust-lang#69916 and [`src/test/mir-opt/README.md`](https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md): > By default 32 bit and 64 bit targets use the same dump files, which can be problematic in the presence of pointers in constants or other bit width dependent things. In that case you can add > > ``` > // EMIT_MIR_FOR_EACH_BIT_WIDTH > ``` > > to your test, causing separate files to be generated for 32bit and 64bit systems. However, if you change the output of such a test (intentionally or not), or if you add a test and it varies between 32-bit and 64-bit platforms, you have to run this command (for a x64 linux host): `./x.py test --stage 1 --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu --bless src/test/mir-opt` Otherwise, bors trying to merge the PR will fail, since we test 32-bit targets there. But we don't on PR CI, which means there's no way the PR author would know (unless they were burnt by this already and know what to look for). This PR resolves that by running `mir-opt` tests for ~~`i686-unknown-linux-gnu`~~, on PR CI. **EDIT**: switched to `armv5te-unknown-linux-gnueabi` to work around LLVM 7 crashes (see rust-lang/compiler-builtins#311 (comment)), found during testing. cc @rust-lang/wg-mir-opt @rust-lang/infra
cc @rust-lang/wg-mir-opt
cc @RalfJung
Long overdue, but now you can finally just add a
// EMIT_MIR rustc.function_name.MirPassName.before.mir(or
after.mirsince most of the time you want to know the MIR after a pass). A--blessinvocation will automatically create the files for you.I suggest we do this for all mir opt tests that have all of the MIR in their source anyway
If you use
rustc.function.MirPass.diffyou only get the diff that the MIR pass causes on the MIR.Fixes#67865