Rolling up PRs in the queue #21919
Merged
Rolling up PRs in the queue #21919
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
* Display::fmt is stable * Debug::fmt is stable * FromIterator::from_iter is stable * Peekable::peek is stable
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
a trait obligation. Partial fix for rust-lang#16440 -- closure return types are not handled yet.
possible. There is some amount of duplication as a result (similar to select) -- I am not happy about this but not sure how to fix it without deeper rewrites.
closure kind, thereby detecting what happens if there are mismatches. Simply removing the `:` annotations caused most of these tests to pass or produce other errors, because the inference would convert the closure into a more appropriate kind. (The ability to override the inference by using the expected type is an important backdoor partly for this reason.)
upgrade the inference based on expected type so that it is able to infer the fn kind in isolation even if the full signature is not available (and we could perhaps do better still in some cases, such as extracting just the types of the arguments but not the return value).
…an the explicit annotation, leading to "extra `mut` declaration" lint errors.
This removes the `ByRef` iterator adaptor to stay in line with the changes to `std::io`. The `by_ref` method instead just returns `&mut Self`. This also removes the implementation of `Iterator for &mut Iterator` and instead generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The `Box<I>` implementations were also updated. This is a breaking change due to the removal of the `std::iter::ByRef` type. All mentions of `ByRef<'a, T>` should be replaced with `&mut T` to migrate forward. [breaking-change]
This commit is an implementation of [RFC 576][rfc] which adds back the `std::io` module to the standard library. No functionality in `std::old_io` has been deprecated just yet, and the new `std::io` module is behind the same `io` feature gate. [rfc]: rust-lang/rfcs#576 A good bit of functionality was copied over from `std::old_io`, but many tweaks were required for the new method signatures. Behavior such as precisely when buffered objects call to the underlying object may have been tweaked slightly in the transition. All implementations were audited to use composition wherever possible. For example the custom `pos` and `cap` cursors in `BufReader` were removed in favor of just using `Cursor<Vec<u8>>`. A few liberties were taken during this implementation which were not explicitly spelled out in the RFC: * The old `LineBufferedWriter` is now named `LineWriter` * The internal representation of `Error` now favors OS error codes (a 0-allocation path) and contains a `Box` for extra semantic data. * The io prelude currently reexports `Seek` as `NewSeek` to prevent conflicts with the real prelude reexport of `old_io::Seek` * The `chars` method was moved from `BufReadExt` to `ReadExt`. * The `chars` iterator returns a custom error with a variant that explains that the data was not valid UTF-8.
This PR implements [path reform](rust-lang/rfcs#474), and motivation and details for the change can be found there. For convenience, the old path API is being kept as `old_path` for the time being. Updating after this PR is just a matter of changing imports to `old_path` (which is likely not needed, since the prelude entries still export the old path API). This initial PR does not include additional normalization or platform-specific path extensions. These will be done in follow up commits or PRs. [breaking-change] Closes rust-lang#20034 Closes rust-lang#12056 Closes rust-lang#11594 Closes rust-lang#14028 Closes rust-lang#14049 Closes rust-lang#10035
This commit is an implementation of [RFC 576][rfc] which adds back the `std::io` module to the standard library. No functionality in `std::old_io` has been deprecated just yet, and the new `std::io` module is behind the same `io` feature gate. [rfc]: rust-lang/rfcs#576 A good bit of functionality was copied over from `std::old_io`, but many tweaks were required for the new method signatures. Behavior such as precisely when buffered objects call to the underlying object may have been tweaked slightly in the transition. All implementations were audited to use composition wherever possible. For example the custom `pos` and `cap` cursors in `BufReader` were removed in favor of just using `Cursor<Vec<u8>>`. A few liberties were taken during this implementation which were not explicitly spelled out in the RFC: * The old `LineBufferedWriter` is now named `LineWriter` * The internal representation of `Error` now favors OS error codes (a 0-allocation path) and contains a `Box` for extra semantic data. * The io prelude currently reexports `Seek` as `NewSeek` to prevent conflicts with the real prelude reexport of `old_io::Seek` * The `chars` method was moved from `BufReadExt` to `ReadExt`. * The `chars` iterator returns a custom error with a variant that explains that the data was not valid UTF-8.
* Display::fmt is stable * Debug::fmt is stable * FromIterator::from_iter is stable * Peekable::peek is stable
Building over night, posting for review now. Presumably not much should need change. I consider this necessary to move forward with a proper stabilization of the API. r? @huonw
|
@bors: r+ 0eb1431 p=100 |
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ de35d96 p=100 |
|
@bors: retry |
|
⌛ Testing commit de35d96 with merge 2435879... |
|
💔 Test failed - auto-win-32-nopt-t |
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
This *almost* completes the job for rust-lang#16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done. As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.) This commit does not *quite* fix rust-lang#16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends. r? @eddyb as he reviewed the prior patch in this direction
This removes the `ByRef` iterator adaptor to stay in line with the changes to `std::io`. The `by_ref` method instead just returns `&mut Self`. This also removes the implementation of `Iterator for &mut Iterator` and instead generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The `Box<I>` implementations were also updated.
Currently, if a `#![staged_api]` crate contains an exported item without a stability marker (or inherited stability), the item is useless. This change introduces a check to ensure that all exported items have a defined stability. it also introduces the `unmarked_api` feature, which lets users import unmarked features. While this PR should in theory forbid these from existing, in practice we can't be so sure; so this lets users bypass this check instead of having to wait for the library and/or compiler to be fixed (since otherwise this is a hard error). r? @aturon
|
cc @dotdash That failure may be of interest to you: |
|
@bors: r+ 406ccee p=100 |
|
⌛ Testing commit 406ccee with merge b8bfbb6... |
|
💔 Test failed - auto-win-32-opt |
|
⌛ Testing commit 70ecd8e with merge d0ca03c... |
|
💔 Test failed - auto-linux-64-opt |
|
@bors: retry |
|
⌛ Testing commit 70ecd8e with merge d6c15d9... |
bors
added a commit
that referenced
this pull request
Feb 4, 2015
1 similar comment
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.
No description provided.