Windows metabug

[brson]

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

Major tasks:

• #16312 64-bit automation
• #16823 Installer naming
• #11782 stop requiring mingw install
• #16456 cargo installation
• #13259 TCB-slot usage
• rust-lang/cargo#326 native dlls
• #16457 run full test suite on bots
• #13810 make install problems
• #17202 debuginfo

Compiler fixes:

• #13256 debugging problems
• #15644 'benign' segfaults
• #15420 static libgcc
• #13794 inconsistent output naming
• #13793 0-length static array
• #13429 float casts
• #11261 which system ABI on win64

Library fixes:

• #16070 MemoryMap::new()
• #15836 fs::rename
• #15522 plugin_registrar ICE
• #5286 x-crate tests
• #13725 regex tests
• #12795 lstat
• #10102 UDP tests
• #8818 dynamic lib tests
• #8755 math test failures
• #16937 process::Command::env

Mysterious crashes:

• #14403
• #15813
• #16324

Other:

• #16654 - docs
• #15717 - triples
• #17260 - broken installer link
• #17251 - incompatibility with system mingw

[cmr]

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)?

[ghost]

@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.

[ghost]

@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.

[frewsxcv]

Visiting for triage: Any updates for any of the items above?

[alexcrichton]

Enough of this has been checked off that I think it's safe to say this can be closed now.