Recommendation of Windows ABI

[leepa]

I notice we still reference that users should use the GNU ABI is 'recommended for typical uses' - however a long chat in IRC yesterday pointed out this has been the recommendation since 1.0 and a lot of work has gone into MSVC since.

I did have look at the outstanding MSVC issues and I'd like to propose that MSVC becomes 'recommended for typical uses' due to the more stable linker and such like.

These days openssl works just fine on the MSVC ABI and you get better backtraces and debug information (hell, you even get a PDB file - awesome).

Even if we don't change the recommendation we should make the choice clearer - from IRC the Windows users definitely have less issues with it then the GNU ABI.

[steveklabnik]

/cc @retep998

[retep998]

I am in favor of changing the recommendation.

[brson]

I'm down. I will also change rustup to default to i686-msvc when I implement host customization.

cc @rust-lang/tools Considering repositioning the MSVC windows toolchains as the default.

[brson]

cc @rust-lang/compiler

[alexcrichton]

Sounds like a plan to me.

[retep998]

Another point, the GNU ABI doesn't even have ASLR enabled, nevermind high entropy ASLR. rust-lang/rust#16514 and rust-lang/rust#16593

[brson]

rustup has host customization now, so we can program the default host to be the msvc target. We're good to pull the trigger on this pretty soon.

[retep998]

Even Microsoft is recommending using MSVC for Rust http://landinghub.visualstudio.com/visual-cpp-build-tools

[leepa]

It's awesome that MS are saying you can build Rust right there on their site!

[vadimcn]

@leepa, @retep998: What's so much better about -msvc toolchain? I'm sure -gnu has its problems, but:

• The -msvc toolchain is not self-contained - you cannot just install it and start compiling Rust code.
• The debug info story is neither here nor there. Yes, you can step the lines in MSVC debugger, but you cannot see the values of variables. LLVM's CodeView emission is being worked on, but is far from complete, as far as I know.
• The compiled binaries depend on a versioned MSVC runtime. Yes, even with VS2015, as we use MSVC's unwinding personality routine, which is not a part of UCRT. This means that authors will need to distribute MSVCRT install package along with their programs.

[retep998]

• I feel this would be much better suited by rustup auto detecting whether you have VS installed and choosing the appropriate default.
• I agree that the debug info situation isn't great, but it's also somewhat complicated to get a good GDB debugging experience on Windows, especially with a GDB recent enough to support the new Rust specific dwarf things.
• This could be solved by statically linking the VC runtime and CRT. Hopefully we can get better control over this in the future Can't statically link MSVC runtime libc#290

[vadimcn]

I feel this would be much better suited by rustup auto detecting whether you have VS installed and choosing the appropriate default.

So running rustup on two different machines could end up installing different flavors, just because one of them already had MSVC installed? Not sure I dig that. Besides, in this case we'd be effectively recommending them both equally?

I agree that the debug info situation isn't great, but it's also somewhat complicated to get a good GDB debugging experience on Windows, especially with a GDB recent enough to support the new Rust specific dwarf things.

Rust-specific DWARF hasn't happened yet. And even then, I hope we'll find a way to keep it backwards-compatible with standard debuggers.

---

Anyhow, IMO, these problems could be tolerated and lived with, had the other alternative been much worse. But really, what's so bad about the -gnu toolchain?

[retep998]

@vadimcn Even if we don't outright recommend -msvc over -gnu, we should still remove the bit that says -gnu is more mature than -msvc because at this point they're both mature tier 1 platforms.

[leepa]

@vadimcn because mingw (-gnu) has a a lot of issues with its linker where in larger projects users have to coerce it into working properly. The -msvc linker is far less fussy. The former also doesn't support things like ASLR which is a real shame in itself. I actually asked about this in the IRC channel on the date of the original raising of the issue - if there's stored IRC logs it'd be worth a read as some Win32 developers gave lots of reasons and example as to why the -gnu is buggy.

[nrc]

I'm also in favour of changing. MSVC is the toolchain for Windows, using anything else is amateurish. GNU is fine as a stepping stone, but long term is not a good solution, and we should be moving towards MSVC as fast as possible.

[Diggsey]

Actually rustup already does look for an MSVC installation and will default to installing the MSVC toolchain if one exists. 😉

[leepa]

In which case that strengthens the argument to change the wording on the main rust-lang/rust-www site.

[brson]

So running rustup on two different machines could end up installing different flavors, just because one of them already had MSVC installed? Not sure I dig that. Besides, in this case we'd be effectively recommending them both equally?

I also am a bit uncomfortable with this unpredictability. Maybe instead it can go ahead with the detection, but instead of making a decision on it's own, print a warning and a link to the download for MSVC. rust-lang/rustup#561

[brson]

I'm in favor of changing the order the GNU/MSVC toolchains are presented and changing the final sentence of the footer to say something about why you should pick MSVC.

[brson]

Might want to wait until after the 1.10 release to make sure there's consensus and we're not surprising people, but most stakeholders are paying attention to this thread.

[vadimcn]

@leepa: I think we should explicitly enumerate which problems with the -gnu toolchain we are trying to avoid by switching to -msvc, so it'd be easier to decide which set of problems is worse. I've checked the IRC logs. It seems like most of the information is coming from @retep998, perhaps he could weigh in on this?

[steveklabnik]

It is post 1.10. Are we ready to do this?