Add a regression test for #29122 (fixed in #29134)

[wthrowe]

I suspect this won't work on Windows, but let's be optimistic and try it before disabling.

[rust-highfive]

r? @alexcrichton

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

[pnkfelix]

@bors r+ rollup

[bors]

📌 Commit 19041cd has been approved by pnkfelix

[steveklabnik]

@bors: r-

this caused rollup failure

[wthrowe]

I've fixed the pretty failures and I think the test should be working on OS X now.

[alexcrichton]

@bors: r+ 9c877c2

[steveklabnik]

@bors: r-

Still caused another failure: #29178

[wthrowe]

I do not understand this new error. There is rustc output indicating a successful compilation of a staticlib, but then the expected staticlib does not exist.

note: link against the following native artifacts when linking against this static library
note: the order and any duplication can be significant on some platforms, and so may need to be preserved
note: library: ws2_32
note: library: userenv
note: library: advapi32
note: library: kernel32
note: library: shell32
note: library: msvcrt
mv: cannot stat '/C/bot/slave/auto-win-msvc-64-opt/build/obj/x86_64-pc-windows-msvc/test/run-make/linker-output-non-utf8/library.lib': No such file or directory
make[1]: *** [all] Error 1

[alexcrichton]

The STATICLIB macro here is expanding to library.lib on Windows when a staticlib output always produces libfoo.a (e.g. liblibrary.a in this case)

[wthrowe]

The reference could use an update, then. (I'm not going to do it because, as shown here, I don't understand what's going on well enough to write something useful.)

I think at this point I'm just going to disable the test on Windows, if no one objects. I expect that the linking command won't work there anyway, and it seems like there might be several more cycles of this before I even figure out how to attempt to link a Windows native library. Someone who can do local testing and actually knows how to develop for Windows can fix it if they want to.

[alexcrichton]

Oh weird! Yeah that documentation should probably be updated!

Could this just hardcode liblibrary.a for now to work on Windows as well? In general we prefer to have tests run everywhere whenever possible.

[wthrowe]

Modified to be a no-op on Windows.

[wthrowe]

(Moving to the main comment thread from line comments.)

Alright, try this version.

I should probably point out that if this does work on Windows and actually tests what it's supposed to then it would seem I've created a file whose name can't be stored in a PathBuf.

[alexcrichton]

Thanks! Could you also squash this down to one commit?

[wthrowe]

Squashed.

[alexcrichton]

@bors: r+ 0dce92a

[bors]

⌛ Testing commit 0dce92a with merge 93429ad...

[alexcrichton]

@bors: r-

I think this caused a legitimate failure

[alexcrichton]

@bors: force

[bors]

⛄ The build was interrupted to prioritize another pull request.

[steveklabnik]

I wasn't sure

[steveklabnik]

Can we not roll this up in the future? It's already caused three rollups to fail.

[steveklabnik]

@bors: rollup-

[wthrowe]

Not much to go on. The failed command is a grep, so in failing it swallowed all the debugging output.

[alexcrichton]

This may actually be a bug in MinGW's gcc because the error I'm seeing is that it can't find -llibrary (even if this is passed as -L).

If that's the case where this just unfortunately doesn't work on Windows then could you add a comment as such before ignoring it?

[wthrowe]

This look good?

[alexcrichton]

@bors: r+ a1c8431

Thanks!

[bors]

⌛ Testing commit a1c8431 with merge d2f41bd...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt