I am not mentioning #[unsafe_drop_flag] because it should go away
eventually, and also because it's just an attribute, it's not
really a use of the `unsafe` keyword.
Fixes#26345
I am not mentioning #[unsafe_drop_flag] because it should go away
eventually, and also because it's just an attribute, it's not
really a use of the `unsafe` keyword.
Fixes#26345
This will add information about the stage that a rustc was built with to the verbose version info
I have symlinks into $(HOST)/stage{0,1,2} into the rust version switcher thing I use, and occasionally need to know which stage a given rustc is.
Each formatting trait now has an example of implementation, as well as a
fuller description of what it's supposed to output.
It also contains a link to the module-level documentation which
Fixes#25765
This will add information about the stage that a rustc was built with to the verbose version info
I have symlinks into $(HOST)/stage{0,1,2} into the rust version switcher thing I use, and occasionally need to know which stage a given rustc is.
Each formatting trait now has an example of implementation, as well as a
fuller description of what it's supposed to output.
It also contains a link to the module-level documentation which
Fixes#25765
the indentation has always been a thorn in my eye.
If it's preferred I'll leave the `unsafe` where it was and change it to
```rust
unsafe { match e.node {
...
} } // unsafe { match e.node {
```
so there's no unnecessary indent
This PR was originally going to be a "let's start running tests on MSVC" PR, but it didn't quite get to that point. It instead gets us ~80% of the way there! The steps taken in this PR are:
* Landing pads are turned on by default for 64-bit MSVC. The LLVM support is "good enough" with the caveat the destructor glue is now marked noinline. This was recommended [on the associated bug](https://llvm.org/bugs/show_bug.cgi?id=23884) as a stopgap until LLVM has a better representation for exception handling in MSVC. The consequence of this is that MSVC will have a bit of a perf hit, but there are possible routes we can take if this workaround sticks around for too long.
* The linker (`link.exe`) is now looked up in the Windows Registry if it's not otherwise available in the environment. This improves using the compiler outside of a VS shell (e.g. in a MSYS shell or in a vanilla cmd.exe shell). This also makes cross compiles via Cargo "just work" when crossing between 32 and 64 bit!
* TLS destructors were fixed to start running on MSVC (they previously weren't running at all)
* A few assorted `run-pass` tests were fixed.
* The dependency on the `rust_builtin` library was removed entirely for MSVC to try to prevent any `cl.exe` compiled objects get into the standard library. This should help us later remove any dependence on the CRT by the standard library.
* I re-added `rust_try_msvc_32.ll` for 32-bit MSVC and ensured that landing pads were turned off by default there as well.
Despite landing pads being enabled, there are still *many* failing tests on MSVC. The two major classes I've identified so far are:
* Spurious aborts. It appears that when optimizations are enabled that landing pads aren't always lined up properly, and sometimes an exception being thrown can't find the catch block down the stack, causing the program to abort. I've been working to reduce this test case but haven't been met with great success just yet.
* Parallel codegen does not work on MSVC. Our current strategy is to take the N object files emitted by the N codegen threads and use `ld -r` to assemble them into *one* object file. The MSVC linker, however, does not have this ability, and this will need to be rearchitected to work on MSVC.
I will fix parallel codegen in a future PR, and I'll also be watching LLVM closely to see if the aborts... disappear!
