Additional commit replaces windows-2016 with windows-2019, because former was removed from Github Actions.

The mingw error after merge is new. Should I look into it? I mean maybe how to fix it is already common knowledge...

It appears to be Windows 2022-specific. Because if I force os to windows-2019 in mingw32 section of the .github/workflows/main.yml, the [test] passes... [Off for today.]

It looks like a miscompile. Maybe a rustc issue? If I try to run the i686-pc-windows-gnu test binary on my machine, this the what the debugger says:

ModLoad: 00400000 009f8000   Z:\target\debug\deps\all-aa90ab550493a218.exe
WARNING: Image Z:\target\debug\deps\all-aa90ab550493a218.exe section 0 extends outside of image bounds
WARNING: Image Z:\target\debug\deps\all-aa90ab550493a218.exe section 1 extends outside of image bounds
DbsSplayTreeRangeMap::Add: Conflicting region 00000000 - 00000407
Unable to map Z:\target\debug\deps\all-aa90ab550493a218.exe region at 00000000, NTSTATUS 0xC0000018
*** WARNING: Unable to verify timestamp for all-aa90ab550493a218.exe
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=004014e0 esp=00000000 ebp=00000000 iopl=0         nv up di pl nz na po nc
cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
all_aa90ab550493a218+0x14e0:
004014e0 ??              ???

That NTSTATUS code is STATUS_CONFLICTING_ADDRESSES ("The specified address range conflicts with the address space").

I haven't investigated further.

Just in case, it's not like it fails to run any mingw32 executable. The prior tests do pass and then it fails --manifest-path cc-test/Cargo.toml. As for which component is to blame. Recall that rustc is calling mingw gcc to link the binary. So it's either rustc driving GNU ld crazy, or GNU ld being crazy by itself. As for 2019 vs. 2022. Corresponding runners are documented to run different mingw versions, 8.1.0 vs. 11.20, so that it's more likely to be specific to mingw version than to Windows.

The prior tests do pass and then it fails --manifest-path cc-test/Cargo.toml

Though you're showing Z:\target\debug\deps\all-xyzzy.exe. More specifically there is no cc-test in the file name. On the other hand it has "all" in it... So it ought to be cc-test/test/all.rs, right?

I am replicating the failed CI test:

  cargo test  --manifest-path cc-test/Cargo.toml --target i686-pc-windows-gnu
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
    Updating crates.io index
 Downloading crates ...
  Downloaded either v1.7.0
  Downloaded lazy_static v1.4.0
  Downloaded which v4.2.5
  Downloaded libc v0.2.126
   Compiling libc v0.2.126
   Compiling either v1.7.0
   Compiling lazy_static v1.4.0
   Compiling cc v1.0.73 (D:\a\cc-rs\cc-rs)
   Compiling which v4.2.5
   Compiling cc-test v0.1.0 (D:\a\cc-rs\cc-rs\cc-test)
    Finished test [unoptimized + debuginfo] target(s) in 21.40s
     Running tests\all.rs (cc-test\target\i686-pc-windows-gnu\debug\deps\all-8b31d61675f10411.exe)
error: test failed, to rerun pass '--test all'
Caused by:
  could not execute process `D:\a\cc-rs\cc-rs\cc-test\target\i686-pc-windows-gnu\debug\deps\all-8b31d61675f10411.exe` (never executed)

I don't know where it "ought" to be. I can only say where it is and that the binary is broken as it won't even load.

Got it! Thanks! It ought to be one of the "unusual" tests in all.rs, "OptLink" or "asm". I'll try to triage...

Hmmm.... I've masked the "OptLink", "asm" and "cpp" tests, and the test in question keeps failing. As mentioned it's mingw gcc, and by extension GNU ld, that does the linking. There is no reason to believe that most basic .c modules would be inconsistent with GNU ld. At the same time one can't say that it's between rustc and GNU ld, because linking pure Rust programs works. Or in other words, GNU ld does not get "confused" by rustc alone. Nor should it get confused by C alone. It gets "confused" specifically by a mixture of libraries compiled by rustc and cc...

OK, the --release builds actually work. Is it possible that it's mingw32 equivalent of #694? I write "equivalent" because DWARF is not used in mingw... Right? Either way, it's not impossible that it's a debugging information mismatch that is driving GNU ld crazy...

the --release builds actually work.

Just in case, all tests work with --release. That is even the "OptLink", "asm" and "cpp".

Ah, yeah, I do think mingw uses DWARF for exception handling. Only msvc targets use SEH currently.

So the workaround for now would be to set the job to windows-2019?

Well, whatever information is there to assist the exception handling is unlikely to be a the problem. Because if it was, then even --release build would be failing...

So the workaround for now would be to set the job to windows-2019?

This was tested and proven to work, yes.

Well, whatever information is there to assist the exception handling is unlikely to be a problem. Because if it was, then even --release build would be failing...

Sure but I mean if it's using DWARF for exception handling then I would be very surprised if it wasn't also using DWARF for debugging symbols.

Opened #697 as temporary workaround.

BTW. Chris! Since you can reproduce it on your computer, could you check if setting CFLAGS and CXXFLAGS environment variables to -gdwarf-2 makes cargo test --manifest-path cc-test/Cargo.toml --target i686-pc-windows-gnu work? This would allow us to figure out if it's the debugging information version mismatch that is the actual problem...

Yep, those flags seem to fix it.

$ CFLAGS=-gdwarf-2 CXXFLAGS=-gdwarf-2 cargo +stable-i686-pc-windows-gnu test --manifest-path cc-test/Cargo.toml --target-dir Z:\\cc-test\\target
   Compiling libc v0.2.126
   Compiling lazy_static v1.4.0
   Compiling either v1.7.0
   Compiling cc v1.0.73 (D:\Projects\cc-rs)
   Compiling which v4.2.5
   Compiling cc-test v0.1.0 (D:\Projects\cc-rs\cc-test)
    Finished test [unoptimized + debuginfo] target(s) in 6.00s
     Running tests\all.rs (Z:\cc-test\target\debug\deps\all-aa90ab550493a218.exe)

running 6 tests
test asm_here ... ok
test bar_here ... ok
test baz_here ... ok
test foo_here ... ok
test opt_linkage ... ok
test windows_here ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Yeah, it looks very much like mingw32 equivalent of #694, I'll leave a note there. Thanks!