PATH variable grows each time compiler is run

[brson]

Trying to turn on windows tests (#16457) I'm now hitting errors like

---- path::GenericPath::set_extension_0 stdout ----
    error: could not exec the linker `gcc`: OS Error 206: The filename or extension is too long.

    error: aborting due to previous error
    task 'path::GenericPath::set_extension_0' failed at 'Box<Any>', C:\bot\slave\auto-win32-32-opt\b\src\libsyntax\ast_util.rs:784

Windows hates long paths.

[brson]

Doesn't reproduce locally so must be related to the length of the temp dir on the bots specifically.

[brson]

The error seems related to this one on so. At some point in execution CreateProcess just starts failing with error 206 and then keeps failing. It doesn't have anything to do with the length of the tmp path.

[brson]

Related Eclipse bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193

[alexcrichton]

I suspect that you may want to fix this block of code to only append something once. Perhaps that's where the huge environment is coming from?

[brson]

With either RUST_TEST_TASKS=1 make check-stage2-doc-crate-core or RUST_TEST_TASKS=1 make check-stage2-doc-crate-std I get 134 passes, then all subsequent tests fail.

[alexcrichton]

In rustdoc all instances of rustc happen in the same process, so that environment variable is just continuously growing.

[brson]

@alexcrichton That is an interesting block of code! With rustdoc running in-process rustc's in parallel this is very racy (though even without parallel tests this is failing).

[brson]

It does seem like a possibility that the environment is accumulating w/o bound

[brson]

@alexcrichton That block of code does try to reset the environment, which seems like it should work sequentially.

[alexcrichton]

It is a bit racy, yes, but I'd be more worried about every test adding the same paths to PATH and it just keeps growing and growing (and the bug report just said that big processes caused problems)

[brson]

There's more racy environment code in phase 6.

[brson]

@alexcrichton This code does try to restore the original PATH. Are you seeing somewhere it doesn't?