Windows metabug

[brson]

These are some of the major outstanding Windows bugs, ordered roughly by priority. Prior discussion

Major tasks:

• Set up automation for 64-bit windows #16312 64-bit automation
• Fix naming of windows dist artifacts #16823 Installer naming
• Package all required components of the MinGW toolchain #11782 stop requiring mingw install
• Figure out combined Rust+Cargo installation #16456 cargo installation
• libnative: main task has bad thread local data on windows #13259 TCB-slot usage
• Windows: Can't place DLLs in load-time link search locations. cargo#326 native dlls
• Run full test suite on windows bots #16457 run full test suite on bots
• make install error on Windows #13810 make install problems
• Most debuginfo tests are broken on 64-bit windows #17202 debuginfo

Compiler fixes:

• test/debug-info: filename extension matters on windows #13256 debugging problems
• Benign segfault in gdb on windows #15644 'benign' segfaults
• rustc -C link-args=-static-libgcc does not work on Windows #15420 static libgcc
• rustc --crate-type=dylib -o name produces name.exe on windows #13794 inconsistent output naming
• zero-length static array triggers LLVM assertion error on windows #13793 0-length static array
• Cast from f64 to f32 not working with latest nightly on Windows #13429 float casts
• Should "system" ABI be "win64" on x86_64 windows? #11261 which system ABI on win64

Library fixes:

• std::os::MemoryMap::new() fails on Windows #16070 MemoryMap::new()
• fs::rename behavior differs on windows #15836 fs::rename
• ICE on Windows when linker output is too large #15522 plugin_registrar ICE
• Cross crate tests on windows are broken #5286 x-crate tests
• Regex tests are ignored on windows #13725 regex tests
• lstat implementation on windows #12795 lstat
• uvio's test_udp_twice function is ignored on windows #10102 UDP tests
• Windows: failing unit tests in libstd\unstable\dynamic_lib.rs #8818 dynamic lib tests
• {f32,f64,float}::tests::test_frexp unit tests in libstd fail on Windows #8755 math test failures
• Windows: process::Command::env should be case-insensitive #16937 process::Command::env

Mysterious crashes:

• Cannot run any rust programs on windows #14403
• rust crashed on windows 8.1(x64) with comodo av #15813
• Able to compile but get "... has stopped working" error on launch in Windows 7 x64 #16324

Other:

• Windows build instructions are inconsistent #16654 - docs
• Clean up i686-{pc, w64}-mingw32 triples #15717 - triples
• Guide- link to Windows Binary gives 404 #17260 - broken installer link
• Windows 32 bits nightlies fail to compile a simple hello world #17251 - incompatibility with system mingw

[emberian]

Somewhat unrelated, but I've started work on a Visual Studio extension as well.

[tomaka]

Note that I've started encountering random crashes on Windows for one of my programs after I switched from using a (native) task to using a std::rt::thread, even though the task was not using I/O at all. Switching back to using a task fixed everything.

I didn't report it because it's very vague and I couldn't reproduce the issue reliably (I spent one or two hours trying to), but there's definitely something wrong with std::rt::thread that doesn't seem to be on this list.

[vadimcn]

Given that we don't want users to have to install msys/mingw, does it even make sense to worry about 'make install' (#13810)?

@vadimcn
Worrying about make install makes sense, as a person might prefer compiling rust with the defaults [though it surely is not high priority] and :-

1. Someone might want to compile rust him/herself maybe for cross-compilation.
2. Someone might want to contribute to the rust windows code-base but he might want to make sure if his changes work as expected.
3. etc. etc.

[retep998]

I just point my PATH at the x86_64-w64-mingw32\stage2\bin folder and I'm able to compile programs with that rustc. I never trust make install on Windows anyway since I have no idea where it will install.

[vadimcn]

@V01D-exe, yes it might be useful. But should it be on the list of v1.0 blockers? I think not.

@vadimcn
Agreed, it should be low-priority as of now.
Later on [maybe after about 1 year ], when rust is stable and windows support becomes properly mature [i.e. no major bugs in the binaries] , then it would be high priority.

Till then, it would be better to modify the windows compilation instructions in readme.md and remove && make install from the last command. Even better to include a note about the current not-working status of make install over there, so that people know that it is bugged. And maybe even better to add retep998's instructions posted above.

[brson]

Nominating. Many of these sub-bugs should be fixed for 1.0.

[iliekturtles]

The nightly installer isn't adding C:\Program Files (x86)\Rust\bin to PATH as the installer advertises. I couldn't find an existing issue. Should one be opened or am I doing something wrong?

[brson]

@iliekturtles Please open an issue, yes.

[iliekturtles]

@brson #17570 opened for discussion. Will submit a patch for one of the proposed solutions shortly.