compiletest: make check-stage1 (or at least check-stage1-cfail) no longer works on clean build dir

[pnkfelix]

When trying to do rustc development on the stage1 compiler, I've been hitting a link error.

I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing check-stage1-cfail (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).

% uname -a
Darwin fklockii-Eris.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
% git log -1 --oneline
1b46b00 auto merge of #17784 : bkoropoff/rust/issue-17780, r=pcwalton
% ../configure --enable-debug --disable-optimize   --enable-ccache --enable-clang --prefix=~/opt/rust-dbg-nopt  && make clean && make check-stage1-cfail
[... expurgated ...]
/Users/pnkfelix/Dev/Mozilla/rust.git/src/compiletest/compiletest.rs:1:1: 1:1 error: can't find crate for `rt`
/Users/pnkfelix/Dev/Mozilla/rust.git/src/compiletest/compiletest.rs:1 // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
                                                                      ^
error: aborting due to previous error
make: *** [x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/bin/compiletest] Error 101

[pnkfelix]

Also, compiletest needs to be written much like rustc itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.

[pnkfelix]

@alexcrichton I know there is well-founded opposition to gating a PR on make check-stage1 passing, but wouldn't just adding compiletest to the set of required build products at each stage during boot strap prevent errors like this in the future?

[pnkfelix]

(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with --local-rust-root have not managed to duplicate the problem here...)

[pnkfelix]

So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler.

But we can and should still try to increase the coverage of bors to handle at least building compiletest from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)

[alexcrichton]

At least building compiletest seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(.

(but compiletest is fast to build)

[pnkfelix]

In case anyone is curious, the problem also occurs on Linux.

I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use --enable-local-rust --local-rust-root=... to test this theory have been somewhat flummoxed by different problems.

[pnkfelix]

It does indeed seem like if I first do make rustc-stage2, after the make clean but before the make check-stage1-cfail, then things proceed just fine.

This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another rustc build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of rustc that I imagine could easily mask a problem like this.

[pnkfelix]

(PR #17940 only fixes the build issue; it does not attempt to add compiletest to the bors cycle.)

[pnkfelix]

(PR #17940 also does not actually fix the problem I mentioned in comment: #17883 (comment) . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)

[pnkfelix]

(I edited the PR description but forgot that github closes issues based on the original commit message.)

I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the compiletest build itself, and also adding mk/ rules that will force bors to gate on compiletest continuing to build.