Change:
PRETTY_DEPS_pretty-rfail = $(RFAIL_TESTS) PRETTY_DEPS_pretty-bench = $(BENCH_TESTS) PRETTY_DEPS_pretty-pretty = $(PRETTY_TESTS) <ins> # The stage- and host-specific dependencies are for e.g. macro_crate_test which pulls in # external crates. PRETTY_DEPS$(1)_H_$(3)_pretty-rpass = PRETTY_DEPS$(1)_H_$(3)_pretty-rpass-full = $$(HLIB$(1)_H_$(3))/stamp.syntax $$(HLIB$(1)_H_$(3))/stamp.rustc PRETTY_DEPS$(1)_H_$(3)_pretty-rfail = PRETTY_DEPS$(1)_H_$(3)_pretty-bench = PRETTY_DEPS$(1)_H_$(3)_pretty-pretty = </ins> PRETTY_DIRNAME_pretty-rpass = run-pass PRETTY_DIRNAME_pretty-rpass-full = run-pass-fulldeps PRETTY_DIRNAME_pretty-rfail = run-fail

Discussion:
When trying to do 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 (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like 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.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
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 from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
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 to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , 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 build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)

(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 build itself, and also adding rules that will force bors to gate on continuing to build.