Add windows-gnu CI and fix tests

[mati865]

One remaining failure:

---- features::feature_off_dylib stdout ----
running `d:\a\1\s\target\debug\cargo.exe build --features f1`
running `d:\a\1\s\target\debug\cargo.exe run -p bar`
thread 'features::feature_off_dylib' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
   Compiling foo v0.0.1 (D:\a\1\s\target\cit\t663\foo)
   Compiling bar v0.0.1 (D:\a\1\s\target\cit\t663\foo\bar)
    Finished dev [unoptimized + debuginfo] target(s) in 0.69s
     Running `target\debug\bar.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"f1"`,
 right: `"no f1"`', bar\src\main.rs:5:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\bar.exe` (exit code: 101)
', crates\cargo-test-support\src\lib.rs:833:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    features::feature_off_dylib

I disassembled the dylibs and cargo run -p bar correctly rebuilt it inside target/debug/deps/ but did not copy it to target/debug. To further confirm, calling cp target/debug/deps/foo.dll target/debug/ manually solved the issue.
Any idea?

---

I left FIXME in places where import lib should be added with #6875.

TOOLCHAIN: nightly-x86_64-pc-windows-gnu can be replaced with beta on Thursday.

[rust-highfive]

r? @Eh2406

(rust_highfive has picked a reviewer for you, use r? to override)

[mati865]

r? @ehuss

[ehuss]

Hm, so there's more detail in #6167 where that test was introduced. Dependency DLL's are not copied into target/debug. This can be a problem if there are DLL's in that directory from running other cargo commands (see #6162 for an example where that can happen). The fix that was implemented relies on the order of directories in PATH (target/debug/deps is first, which contains all the latest DLLs).

I'm a bit confused why the gnu toolchain has a different search order. I tried to find something useful in https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order, but that only confused me more. It says "The directory from which the application loaded." is first, so I would assume that test should fail with MSVC (we launch the executable in target/debug which has the old foo.dll).

So, anyways, I'm guessing something in the GNU setup is changing the search order to include the binary's directory before PATH.

One possibility is to go with option 3 described at #6162 (comment), where all dependency DLLs should be copied to target/debug. I'm not sure how hard that is to implement.

"Uplifting" is done here. The outputs of each unit are computed in calc_outputs_rustc. The decision to only uplift the "root" units is done here. Maybe that should also say || unit.target.is_dylib()? That way every DLL for each dependency will get copied to target/debug.

[ehuss]

I'd like to keep this on nightly permanently, so that we have some nightly testing for Windows (which enables a bunch of tests that are usually ignored).

[mati865]

MinGW and MSVC both use the same library loader from the OS.

Somehow MSVC creates hardlinks but MinGW copies foo.dll:

$ fsutil hardlink list target/debug/foo.dll
\cargo\target\cit\t663\foo\target\debug\foo.dll

$ fsutil hardlink list target/x86_64-pc-windows-msvc/debug/foo.dll
\cargo\target\cit\t663\foo\target\x86_64-pc-windows-msvc\debug\deps\foo.dll
\cargo\target\cit\t663\foo\target\x86_64-pc-windows-msvc\debug\foo.dll

EDIT:
Hardlink is created properly but cargo run -p bar unlinks it on windows-gnu.

[ehuss]

Ah, good observation. My guess would be a difference in linker behavior. In the presence of an existing file, MSVC probably truncates and modifies, preserving the hardlink, whereas gnu probably replaces the file, breaking the hardlink (at least, that's my guess).

Awesome, thanks for helping!

[ehuss]

@bors r+

[bors]

📌 Commit 2dd0b0d has been approved by ehuss

[bors]

⌛ Testing commit 2dd0b0d with merge 97d39ae...

[mati865]

In the presence of an existing file, MSVC probably truncates and modifies, preserving the hardlink, whereas gnu probably replaces the file, breaking the hardlink (at least, that's my guess).

I had tested LLD before and it failed the same way with gnu target. Lld-link with msvc target had no errors.

[bors]

☀️ Test successful - checks-azure
Approved by: ehuss
Pushing 97d39ae to master...