Change:
<del> // 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 `-o` 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 a non-existent path, which // also used to ICE, but even root can't magically write there. // compile-flags: -Z temps-dir=/does-not-exist/output // The error-pattern check occurs *before* normalization, and the error patterns // are wildly different between build environments. So this is a cop-out (and we // rely on the checking of the normalized stderr output as our actual // "verification" of the diagnostic). // error-pattern: error // On Mac OS X, we get an error like the below // normalize-stderr-test "failed to write bytecode to /does-not-exist/output.non_ice_error_on_worker_io_fail.*" -> "io error modifying /does-not-exist/" // On Linux, we get an error like the below // normalize-stderr-test "couldn't create a temp dir.*" -> "io error modifying /does-not-exist/" // ignore-windows - this is a unix-specific test // ignore-emscripten - the file-system issues do not replicate here // ignore-wasm - the file-system issues do not replicate here // ignore-arm - the file-system issues do not replicate here, at least on armhf-gnu #![crate_type = "lib"] #![cfg_attr(not(feature = "std"), no_std)] pub mod task { pub mod __internal { use crate::task::Waker; } pub use core::task::Waker; } </del>

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.