Fix make check-stage1

[eefriedman]

stage1 rustc doesn't support catching panics, so we have to just kill
the whole process on a fatal error. This is a little hacky... but it's not
very much code, and we only use it for stage1 compilers.

Also, use stage2 compiletest to run tests.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[Gankro]

:O

Fantastic!

💯

[alexcrichton]

Out of curiosity, could you measure the different in compile time for just not passing -Z no-landing-pads at stage0? The benefit may not outweigh the cost any more.

[jonas-schievink]

I hope I did this right, but this is my result (on 64-bit Win10):

With no-landing-pads:

$ ../configure && time make -j4 rustc-stage1

real    11m20.300s
user    0m13.254s
sys     0m23.901s

With landing pads (enabled by commenting out this line):

$ ../configure && time make -j4 rustc-stage1

real    13m10.085s
user    0m13.870s
sys     0m29.292s

[bluss]

Does this allow running the testsuite at stage0 or stage1? The testsuite is essential for developing & contributing to libstd etc.

My patience with rust's long develop-compile-test cycles is already stretched pretty thin, if we go ahead to speed up full bootstrap at the cost of using tests at all, then something is missing. Something like ./configure --i-actually-work-here so that you can use the stage0 and/or stage1 testsuite for development.

[jonas-schievink]

make check-stage1 works, check-stage0 doesn't because make can't build compiletest (I believe this PR contains a fix for that)

[alexcrichton]

I think I'd be in favor of just removing -Z no-landing-pads from the stage0 build. It was always a bit of hack and it's something that should be supported in a more official capacity anyway.

Thoughts @brson?

[tamird]

OTOH, 2 minutes is not nothing.

[bluss]

2 minutes are great savings, but maybe we can have a debug or developer switch that toggles it so that we can work productively on libs, for example using the stage0 tests?

[alexcrichton]

Sure, I agree that 2 minutes is nice to save, but there are downsides:

• We already have a bajillion options in our configure script, and I'd rather not add yet-another-obscure-option.
• Seems like there's quite a desire to get tests working at stage0/1, and the only way to robustly do so is to enable landing pads right now.

[jonas-schievink]

This also wasn't done on the fastest machine. What are the specs of the build bots? (alternatively someone could test/extrapolate the percentage bootstrap time saved by this to get a better metric, I didn't do that because my total time actually decreased which I suspect was due to noise)

[Gankro]

@jonas-schievink Note that buildbot is massively bottlenecked on Windows running an entire extra stage anyway. Most of the bots idle long before windows finishes up.

disregard I need sleep

[eefriedman]

Ping. I've seen three possibilities proposed: this PR, a patch to remove the -Z no-landing-pads flag, and doing nothing because nobody cares enough.

[bluss]

I'd prefer a configure option if we don't outright remove this bootstrap optimization. I don't think this is just for me, those actually working on rust need unwinding while testing their contributions and the test suite.

I saw @nikomatsakis wanted to know how to turn this off too.

[nikomatsakis]

Yes, I second the request for a configure flag. Perhaps tied to enable debug (which in my ideal world would not disable optimizations, but I guess that is orthogonal)

-------- Original message --------

From: bluss notifications@github.com

Date:08/19/2015 08:10 (GMT-05:00)

To: rust-lang/rust rust@noreply.github.com

Cc: Niko Matsakis niko@alum.mit.edu

Subject: Re: [rust] Fix make check-stage1 (#27417)

I'd prefer a configure option if we don't outright remove this bootstrap optimization. I don't think this is just for me, those actually working on rust need unwinding while testing their contributions and the test suite.

I saw @nikomatsakis wanted to know how to turn this off too.

—
Reply to this email directly or view it on GitHub.

[alexcrichton]

For now let's take the route of just tying -Z no-landing-pads in stage0 to --enable-debug, I'm still worried about this patch as-is with respect to the output on panics because we do somewhat rely on output being captured and then emitted on the other side of the panic (e.g. what's read in the monitor function).

Just tying to --enable-debug would be nice and simple and keep things generally working as they currently are.

[arielb1]

@alexcrichton

Well, it USED to WORK with -Z no-landing-pads before you BROKE it. I guess this could be fixed when we get a panic_handler API.

[alexcrichton]

Closing due to inactivity, and given the discussion on the discuss thread I've opened #28710 to track this.