Change:
<ins> # only-linux # ignore-arm - linker error on `armhf-gnu` include ../tools.mk # Issue #66530: We would ICE if someone compiled with `-o /dev/null`, # because we would try to generate auxiliary files in `/dev/` (which # at least the OS X file system rejects). # # An attempt to `-Ztemps-dir` into a directory we cannot write into should # indeed be an error; but not an ICE. # # However, some folks run tests as root, which can write `/dev/` and end # up clobbering `/dev/null`. Instead we'll use an inaccessible path, which # also used to ICE, but even root can't magically write there. # # Note that `-Ztemps-dir` uses `create_dir_all` so it is not sufficient to # use a directory with non-existing parent like `/does-not-exist/output`. all: # Create an inaccessible directory mkdir $(TMPDIR)/inaccessible chmod 000 $(TMPDIR)/inaccessible # Run rustc with `-Ztemps-dir` set to a directory # *inside* the inaccessible one, so that it can't create it $(RUSTC) program.rs -Ztemps-dir=$(TMPDIR)/inaccessible/tmp 2>&1  | $(CGREP) "failed to find or create the directory specified by `--temps-dir`" # Make the inaccessible directory accessible, # so that compiletest can delete the temp dir chmod +rw $(TMPDIR)/inaccessible </ins>

Discussion:
The test fails for me locally on the master branch (and was failing for a while now). I can of course ignore it, but it's annoying. also fails if run after/with . It looks like successfully creates a temp directory even if it's parent does not exist: <details<summaryoutput</summary<p</p</detailsThis causes the failure (as the test is expected to not compile) and also creates the directory, which then observes and also fails. This happens for me on the . cc iirc you had the same problems cc you changed those tests at some point, so maybe you know something
Summing up findings from discord, This test is wrong in its entirity since it gambles on permissions. The underlying subcommand creates the dir if you have enough permission to create in so it would fail. Otherwise, the directory is never created due to insufficient user permission, so the test passes. To sum it up, the test passed (for me) since I did not have enough permission to create a new directory () in : !
The test assumes that the compiler uses and so it must fail to create , but this is actually not the case: The test happens to pass in the CI and for many developers because you generally can't create a directory in . However this is not always the case (for example I happen to run tests in chroot). suggests that the proper fix for the test would be for the test to create an inaccessible directory, basically making a analog to
That still doesn't work if you're the root user, but I guess that's not what you're doing in your chroot? You could use a path like where even root can't create anything, but there's no OS-agnostic path like that.
I guess my point is that was broken on root anyway (because root has access to , same as in chroot). The explanation in the test was because of the original test it looks like, which works because it uses which requires at least the "parent must exist". So change -- now works on root, but doesn't work on chroot anymore does not work on root/chroot, but also doesn't clobber My change: unchanged now works in chroot Sooo, while fails on root, since it doesn't have global effects (clobbering as it originally did), I don't think it's a big deal.

IMO you are not supposed to run tests on root (but it's also bad for tests to have global effects)...
Yeah, that's fair -- we don't have to support root, but it should at least do no harm. While you're poking at that, maybe you can fix the filename spelling to "inaccessible"?
Fixed the spelling, thanks.