Rollup of 6 pull requests #26798
Merged
Rollup of 6 pull requests #26798
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: reference: improve readability of type inference explanations for flo… #26785, reference: make tuple usage examples more meaningful #26787, reference: that looks like exclamations marks for some fonts #26788, reference: tiny fixes #26791, reference: improve lambda example #26792, reference: fix typo #26795
- Failed merges: reference: miscellaneous fixes #26796
This is usually the link I want when I come to this page.
To improve our substring search performance, revive the two way searcher and adapt it to the Pattern API. Fixes rust-lang#25483, a performance bug: that particular case now completes faster in optimized rust than in ruby (but they share the same order of magnitude). Much thanks to @gereeter who helped me understand the reverse case better and wrote the comment explaining `next_back` in the code. I had quickcheck to fuzz test forward and reverse searching thoroughly. The two way searcher implements both forward and reverse search, but not double ended search. The forward and reverse parts of the two way searcher are completely independent. The two way searcher algorithm has very small, constant space overhead, requiring no dynamic allocation. Our implementation is relatively fast, especially due to the `byteset` addition to the algorithm, which speeds up many no-match cases. A bad case for the two way algorithm is: ``` let haystack = (0..10_000).map(|_| "dac").collect::<String>(); let needle = (0..100).map(|_| "bac").collect::<String>()); ``` For this particular case, two way is not much faster than the naive implementation it replaces.
Use a trait to be able to implement both the fast search that skips to each match, and the slower search that emits `Reject` intervals regularly. The latter is important for uses of `next_reject`.
This is needed to not drop performance, after the trait-based changes. Force separate versions of the next method to be generated for the short and long period cases.
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.
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.
r? @eddyb This doesn't seem to make any code valid because the `IndexMut` impls are missing.
core: Use memcmp in is_prefix_of / is_suffix_of The basic str equality in core::str calls memcmp, re-use the same function in StrSearcher's is_prefix_of, is_suffix_of.
`MethodCallee` now has no information about the method, other than its `DefId`. The previous bits of information can be recovered as follows: ```rust let method_item = tcx.impl_or_trait_item(callee.def_id); let container = method_item.container(); ``` The method is inherent if `container` is a `ty::ImplContainer`: * the `impl` the method comes from is `container.id()` The method is a trait method if `container` is a `ty::TraitContainer: * the `trait` the method is part of is `container.id()` * a `ty::TraitRef` can be constructed by putting together: * `container.id()` as the `trait` ID * `callee.substs.clone().method_to_trait()` as the `trait` substs (including `Self`) * the above `trait_ref` is a valid `T: Trait<A, B, C>` predicate * selecting `trait_ref` could result in one of the following: * `traits::VtableImpl(data)`: static dispatch to `data.impl_def_id` * `traits::VtableObject(data)`: dynamic dispatch, with the vtable index: `traits::get_vtable_index_of_object_method(tcx, data, callee.def_id)` * other variants of `traits::Vtable`: various other `impl` sources
Spotted a compiled function call to num::usize::min_value, I'd prefer the 0 to be inlined.
Add missing #[inline] to min_value/max_value on integers Spotted a compiled function call to num::usize::min_value, I'd prefer the 0 to be inlined.
…at and integer types
The sentences are also so short that they don't need periods at the end
…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
|
@bors: r+ p=100 |
|
📌 Commit 89d7dd1 has been approved by |
|
(rust_highfive has picked a reviewer for you, use r? to override) |
bors
added a commit
that referenced
this pull request
Jul 5, 2015
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.