Rollup of 10 pull requests #26844
Merged
Rollup of 10 pull requests #26844
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
steveklabnik
commented
Jul 7, 2015
steveklabnik
commented
- Successful merges: stage info #26599, FFI panic is UB #26761, rustc_trans: always use normalizing_infer_ctxt. #26807, liblibc: correct Linux ioctl request type #26809, Link to test suite information from CONTRIBUTING.md #26825, Document _ in bindings #26827, Significantly improve formatter trait docs #26828, Add note about special make targets #26832, reference: do not display the extra space #26834, reference: make 'Move and copied types' section more simple #26835
- Failed merges: reference: miscellaneous fixes #26796
This commit turns on landing pads for MSVC by default, which means that we'll now be running cleanups for values on the stack when an exception is thrown. This commit "fixes" the previously seen LLVM abort by attaching the `noinline` attribute to all generated drop glue to prevent landing pads from being inlined into other landing pads. The performance of MSVC is highly likely to decrease from this commit, but there are various routes we can taken in the future if this ends up staying for quite a while, such as generating a shim function only called from landing pads which calls the actual drop glue, and this shim is marked noinline. For now, however, this patch enables MSVC to successfully bootstrap itself!
This commit alters the compiler to no longer "just run link.exe" but instead probe the system's registry to find where the linker is located. The default library search path (normally found through LIB) is also found through the registry. This also brings us in line with the default behavior of Clang, and much of the logic of where to look for information is copied over from Clang as well. Finally, this commit removes the makefile logic for updating the environment variables for the compiler, except for stage0 where it's still necessary. The motivation for this change is rooted in two positions: * Not having to set up these environment variables is much less hassle both for the bootstrap and for running the compiler itself. This means that the compiler can be run outside of VS shells and be run inside of cmd.exe or a MSYS shell. * When dealing with cross compilation, there's not actually a set of environment variables that can be set for the compiler. This means, for example, if a Cargo compilation is targeting 32-bit from 64-bit you can't actually set up one set of environment variables. Having the compiler deal with the logic instead is generally much more convenient!
Just like the original article our Windows TLS support is based on predicted, this symbol must be linked in on MSVC to pull in the necessary support for TLS variables. This commit fixes a number of unit tests which require that TLS destructors are run.
The MSVC compiler doesn't like empty structs, so this test won't link on MSVC, so it's ignored.
The function is apparently just called lgamma on MSVC
This library has no shims which are actually needed on Windows now, so translate that last easy one into Rust and then don't link it at all on Windows.
This is currently quite buggy in LLVM from what I can tell, so just disable it entirely. This commit also adds preliminary support, however, to actually target 32-bit MSVC by making sure the `rust_try_msvc_32.ll` file exists and wiring up exceptions to `_except_handler3` instead of `__C_specific_handler` (which doesn't exist on 32-bit).
astconv is called when converting the type-parameter, which leads to a crash. Fixes rust-lang#26812.
…brson 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!
I incorrectly stated that it's an abort.
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 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.
…chton I incorrectly stated that it's an abort. r? @gankro
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 rust-lang#25765
|
@bors: r+ p=100 |
|
📌 Commit 04a85c5 has been approved by |
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
I swear this is the last one today, but since I can sneak another two into it, seems good. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.