Rollup of 8 pull requests #28052
Merged
Rollup of 8 pull requests #28052
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
* Rename `utf16_items` to `decode_utf16`. "Items" is meaningless. * Move it to `rustc_unicode::char`, exposed in `std::char`. * Generalize it to any `u16` iterable, not just `&[u16]`. * Make it yield `Result` instead of a custom `Utf16Item` enum that was isomorphic to `Result`. This enable using the `FromIterator for Result` impl. * Add a `REPLACEMENT_CHARACTER` constant. * Document how `result.unwrap_or(REPLACEMENT_CHARACTER)` replaces `Utf16Item::to_char_lossy`.
The implementation of the remainder operation belongs to librustc_trans, but it is also stubbed out in libcore in order to expose it as a trait on primitive types. Instead of exposing some implementation details (like the upcast to `f64` in MSVC), use a minimal implementation just like that of the `Div` trait.
Reserving lower_bound bytes was just silly. It’d be perfectly reasonable to have empty strings in the iterator, which could cause superfluous reallocation of the string, or to have more than one byte per string, which could cause additional reallocation (in practice it’ll balance out). The added complexity of this logic is simply pointless, adding a little bloat with no demonstrable advantage and slight disadvantage.
Identifying entry points will be useful in --test mode, which is handled in libsyntax.
This handles the case where the #[main] function is buried deeper in the ast than we search for #[test] functions. I'm not sure why one would want to do that, but since it works in standard compilation it should also work for tests.
…-implementation, r=bluss Reserving lower_bound bytes was just silly. It’d be perfectly reasonable to have empty strings in the iterator, which could cause superfluous reallocation of the string, or to have more than one byte per string, which could cause additional reallocation (in practice it’ll balance out). The added complexity of this logic is simply pointless, adding a little bloat with no demonstrable advantage and slight disadvantage.
- Successful merges: rust-lang#27905, rust-lang#27968, rust-lang#27978, rust-lang#27982, rust-lang#27988 - Failed merges:
According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx: > If the function succeeds, the return value is the number of TCHARs stored in the output buffer, > excluding the terminating null character.
This makes it more uniform. No functional changes.
These have been removed and should not be documented here.
…richton According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx: > If the function succeeds, the return value is the number of TCHARs stored in the output buffer, > excluding the terminating null character. _**Completely untested**_… since I have no Windows machine or anything of a sort to test this on. r? @aturon
The issues that the comments referred to were fixed before the PR even landed but we never got around to remove the hack of skipping the lifetime start.
Combining them seemed like a good idea at the time, but turns out that handling lifetimes separately makes it somewhat easier to handle cases where we don't want the intrinsics, and let's you see more easily where the start/end pairs are.
This does cause some breakage due to deficiencies in resolve - `path::Components` is both an `Iterator` and implements `Eq`, `Ord`, etc. If one calls e.g. `partial_cmp` on a `Components` and passes a `&Components` intending to target the `PartialOrd` impl, the compiler will select the `partial_cmp` from `Iterator` and then error out. I doubt anyone will run into breakage from `Components` specifically, but we should see if there are third party types that will run into issues. `iter::order::equals` wasn't moved to `Iterator` since it's exactly the same as `iter::order::eq` but with an `Eq` instead of `PartialEq` bound, which doensn't seem very useful. I also updated `le`, `gt`, etc to use `partial_cmp` which lets us drop the extra `PartialEq` bound. cc rust-lang#27737 r? @alexcrichton
The old code is temporarily needed in order to keep the MSVC build working. It should be possible to remove this code after the bootstrap compiler is updated to contain the MSVC workaround from rust-lang#27875.
The implementation of the remainder operation belongs to librustc_trans, but it is also stubbed out in libcore in order to expose it as a trait on primitive types. Instead of exposing some implementation details (like the upcast to `f64` in MSVC), use a minimal implementation just like that of the `Div` trait.
It was pointing at the issue for `placement_new_protocol`.
The major change here is in the tiny commit at the end and makes it so that we no longer emit lifetime intrinsics for allocas for function arguments. They are live for the whole function anyway, so the intrinsics add no value. This makes the resulting IR more clear, and reduces the peak memory usage and LLVM times by about 1-4%, depending on the crate. The remaining changes are just preparatory cleanups and fixes for missing lifetime intrinsics.
…teveklabnik As of now, when you open a page in the Rust book and other books made with `rustbook`, you cannot scroll with your keyboard, whether using spacebar or arrow keys, unless you explicitly focus on the content div by clicking. This PR fixes the issue by removing the bound on the content div size and by sticking the TOC with `position: fixed` rather than restricting the content to the window height. r? @steveklabnik
We were using them for every expansion, instead of using `Name`. Also converted `CompilerExpansion` into an enum so its nicer to use and takes up less space. Will profile later, but this should be a small improvement in memory usage. r? @eddyb
…er, r=alexcrichton Fixes rust-lang#27996. Does this need any `#[stable]`/`#[unstable]` attributes?
|
@bors r+ p=10 |
|
📌 Commit a63cd9b 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
Aug 27, 2015
|
⌛ Testing commit a63cd9b with merge 8dba06a... |
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.
Stringfrom ExpnInfo #28033, core: Implement IntoIterator for Option and Result references #28039, remove calls to deprecatediter::orderfunctions #28045, Some extra examples for the unimplemented! macro #28048