Make remote-test-client and remote-test-server compatible with windows

[seritools]

compiletest and remote-test-client:

The command line for remote-test-client was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path
with :. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client.

remote-test-server:

• Marked Unix-only parts as such and implemented Windows alternatives
• On Windows LD_LIBRARY_PATH doesn't exist. Libraries are loaded from PATH though, so that's the way around it.
• Tiny cleanup: Command::args/envs instead of manually looping over them
• The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Mark-Simulacrum]

I can't be sure this is correct for Windows, but it largely seems fine to me. Left one nit.

[nikomatsakis]

Good example where I would want to ping the windows group, once it's setup. For now, cc @retep998 and @rylev to check briefly the assertions about PATH and LD_LIBRARY_PATH above.

r=me otherwise.

[seritools]

Just for reference: DLL Search Order for Desktop Applications

EDIT: Similar handling for DLL loading here

[rylev]

Pinging @kennykerr and @sivadeilra as well.

[retep998]

The PATH handling looks fine to me.

[kennykerr]

Looks good.

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 94b7d27d3b7b59a55cf7ee66709cebeb25ea99ae has been approved by Mark-Simulacrum

[tblah]

I think dst should be path here

[seritools]

Argh, yes! Really gotta setup WSL2 or a VM to test this, will do that later today.

(Is there a way to quickly run the equivalent of cargo check for different targets that don't support building form the host?)

[tblah]

You can use cross
e.g.

cross check --target x86_64-unknown-linux-gnu

[seritools]

Thanks, will check it out later today

[seritools]

What's the correct procedure here? I guess bors is gonna fail the merge when trying to test anything that's tested via the remote server. Can the new commit be re-submitted before it has to do all of that? 😅

( @nikomatsakis )

[Mark-Simulacrum]

It's automatically removed from queue if new commits are pushed, though there is the edge case of already being in a rollup. I think we're all good here though, so let's @bors r+

[bors]

📌 Commit 36d6791 has been approved by Mark-Simulacrum

[seritools]

Gotcha, thanks!

[RalfJung]

Failed in #72786 (comment).
@bors r-

[seritools]

Wow, the error seems weird :S Can't see any reason why this shouldn't run on arm-unknown-linux-gnueabihf. (Exact CI log line here)

I've manually compiled and opened for that target it via cross inside a linux/WSL2 VM and it behaves just like it should, only panicking if the parameter is missing or invalid. I don't see however how that parameter could be either of that, it's unconditionally added by compiletest. I didn't find any other location where the remote-test-client is called, either :(

While testing I've noticed that the client has a help text that I didn't update before, so I've done that to align it with the new parameters.

Any ideas?

r? @Mark-Simulacrum

[Mark-Simulacrum]

Oh, I forgot -- I think we also need to update

rust/src/bootstrap/test.rs

Line 1773 in 4512721

format!("{} run", builder.tool_exe(Tool::RemoteTestClient).display()),

and

rust/src/bootstrap/test.rs

Line 1891 in 4512721

let tool = builder.tool_exe(Tool::RemoteTestClient);

which both call remote-test-client outside of compiletest.

I'm not sure what the second place there is doing but the first one is using cargo's support for test runners, loosely documented here -- https://doc.rust-lang.org/nightly/cargo/reference/config.html?highlight=runner#targettriplerunner -- though as we're setting the environment variable I suspect we can't use arrays.

[seritools]

Ohh, now everything makes sense!

The arguments will be passed to the runner with the executable to run as the last argument.

Because of this I think we have to move the submodule count before the executable, should be doable :)

It doesn't seem like the cargo runner has a way of supplying support libs anyways, so setting it to 0 should be fine.

About the second occurrence (l. 1891): That one is for the spawn-emulator subcommand which is unchanged though all of this.

[seritools]

Alright! Let's give it another shot if everything looks good.
@Mark-Simulacrum

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

📌 Commit 036da3a has been approved by Mark-Simulacrum

[Dylan-DPC-zz]

@bors p=1

[bors]

⌛ Testing commit 036da3a with merge eeaf497...

[bors]

☀️ Test successful - checks-azure
Approved by: Mark-Simulacrum
Pushing eeaf497 to master...