Rollup of 5 pull requests #26811
Merged
Rollup of 5 pull requests #26811
Conversation
This file contains hidden or 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 5, 2015
steveklabnik
commented
- Successful merges: remove redundant Send and Sync impl from Vec #26464, reference: improve examples of the different array types #26789, reference: remove stray comma #26800, collections: vec_deque: rename "ringbuf" to "VecDeque" in doc comments #26806, reference: inherits is more clear than implies #26808
- Failed merges: reference: miscellaneous fixes #26796
This logic applies to all MSVC targets, so instead refactor it into platform.mk so it can one day apply to 32-bit MSVC.
Now that LLVM has been updated, the only remaining roadblock to implementing unwinding for MSVC is to fill out the runtime support in `std::rt::unwind::seh`. This commit does precisely that, fixing up some other bits and pieces along the way: * The `seh` unwinding module now uses `RaiseException` to initiate a panic. * The `rust_try.ll` file was rewritten for MSVC (as it's quite different) and is located at `rust_try_msvc_64.ll`, only included on MSVC builds for now. * The personality function for all landing pads generated by LLVM is hard-wired to `__C_specific_handler` instead of the standard `rust_eh_personality` lang item. This is required to get LLVM to emit SEH unwinding information instead of DWARF unwinding information. This also means that on MSVC the `rust_eh_personality` function is entirely unused (but is defined as it's a lang item). More details about how panicking works on SEH can be found in the `rust_try_msvc_64.ll` or `seh.rs` files, but I'm always open to adding more comments! A key aspect of this PR is missing, however, which is that **unwinding is still turned off by default for MSVC**. There is a [bug in llvm][llvm-bug] which causes optimizations to inline enough landing pads that LLVM chokes. If the compiler is optimized at `-O1` (where inlining isn't enabled) then it can bootstrap with unwinding enabled, but when optimized at `-O2` (inlining is enabled) then it hits a fatal LLVM error. [llvm-bug]: https://llvm.org/bugs/show_bug.cgi?id=23884
If a dylib doesn't actually export any symbols then link.exe won't emit a `foo.lib` file to link against (as one isn't necessary). Detect this case in the backend by omitting the `foo.lib` argument to the linker if it doesn't actually exist.
Makes this test case more robust by using standard libraries to ensure the binary can be built.
My bad!
I found some typos in the upcoming 1.1 release note. I corrected them, but I wanted to go further. So I wrote a script that checks the integrity of the Markdown references, and ran it against `RELEASES.md`. This commit fixes some trivial cases, but also removes the following "unused" references: - [`Iterator::cloned`](http://doc.rust-lang.org/nightly/core/iter/trait.Iterator.html#method.cloned) - [`thread::scoped`](http://static.rust-lang.org/doc/master/std/thread/fn.scoped.html) - [`Debug` improvements](https://github.com/rust-lang/rfcs/blob/master/text/0640-debug-improvements.md) - [Rebalancing coherence.](rust-lang/rfcs#1023) However, I think there's a possibility that these features might need to get descriptions as well. How do you feel about it?
…tsakis @nikomatsakis and I ran into this earlier and I figured we should rename the trait and method to match the typical naming convention.
Fix rust-lang#26537. Signed-off-by: OGINO Masanori <[email protected]>
This removes a footgun, since it is a reasonable assumption to make that pointers to `T` will be aligned to `align_of::<T>()`. This also matches the behaviour of C/C++. `min_align_of` is now deprecated. Closes rust-lang#21611.
Storing them as FCAs is a regression from the recent change that made fat pointers immediate return values so that they are passed in registers instead of memory.
Storing them as FCAs is a regression from the recent change that made fat pointers immediate return values so that they are passed in registers instead of memory.
I found some typos in the upcoming 1.1 release note. I corrected them, but I wanted to go further. So I wrote a script that checks the integrity of the Markdown references, and ran it against `RELEASES.md`. This commit fixes some trivial cases, but also removes the following "unused" references: - [`Iterator::cloned`](http://doc.rust-lang.org/nightly/core/iter/trait.Iterator.html#method.cloned) - [`thread::scoped`](http://static.rust-lang.org/doc/master/std/thread/fn.scoped.html) - [`Debug` improvements](https://github.com/rust-lang/rfcs/blob/master/text/0640-debug-improvements.md) - [Rebalancing coherence.](rust-lang/rfcs#1023) However, I think there's a possibility that these features might need to get descriptions as well. How do you feel about it?
… and documentation.
These will first be deprecated in 1.2.0, not 1.1.0.
…at and integer types
…teveklabnik The sentences are also so short that they don't need periods at the end
One is for grammar, and the other is for clarity
…bnik One is for grammar, and the other is for clarity
- Successful merges: rust-lang#26785, rust-lang#26787, rust-lang#26788, rust-lang#26791, rust-lang#26792, rust-lang#26795 - Failed merges: rust-lang#26796
…crichton jit support was removed from rustc in 6b34ba2 (December 2013), so passing `--jit` wouldn't even work.
Fixes rust-lang#24249 I've tagged all items that were missing docs to allow them to compile for now, the ones in core/num should probably be documented at least. This is also a breaking change for any crates using `#[deny(missing_docs)]` that have undocumented constants, not sure there is any way to avoid this without making it a separate lint?
Vec contains `Unique<T>` and some usizes, this is already derived.
|
@bors: r+ p=1 |
|
📌 Commit d1fcb2f has been approved by |
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
💔 Test failed - auto-win-gnu-64-opt |
|
@bors: retry On Sun, Jul 5, 2015 at 6:02 PM, bors [email protected] wrote:
|
|
⚡ Previous build results for auto-linux-64-nopt-t, auto-win-gnu-64-nopt-t are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-opt... |
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.