Rolling up PRs in the queue #20733
Merged
Rolling up PRs in the queue #20733
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
link, but this does the same thing.
Consult the issue rust-lang#20460
This change fixes the issue rust-lang#20460
These tests have all been failing spuroiusly on Windows from time to time, and one suspicion is that the shilc thread outliving the main thread somehow causes the problem. Switch all the tests over to using Thread::scoped instead of Thread::spawn to see if it helps the issue. cc rust-lang#19120
Due to the CSS changes done by the previous patch to make the line numbers clickable (rust-lang#20092), the sidebar became unclickable. This commit reverts the changes and adopts an alternative approach.
always were but it's dang annoying to weed out all the places that fail to meet the assertion, and it doesn't really hurt things if we don't always get it right.
`ty_fold::erase_regions`; also erase regions whenever we normalize associated types.
…ssing the debruijn index in so that callees could construct late-bound regions at the right depth, but then the result was cached. When the cached result was used, it might be at the wrong depth. So now we don't pass the result in and instead simply adjust the depth to match the current nesting level as we go.
caused me quite a bit of hair-pulling.
This allows the vanilla libary to built for kernel use with Cargo.
…ure = external_*)
This PR introduces `isize` and `usize` modules to `core` and `std`, and deprecates the existing `int` and `uint` modules. The rustdoc primitive type links now point to these new modules. Due to deprecation this is a: [breaking-change]
Closes rust-lang#20421 [breaking-change]
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
This changes a line that has `\n#[stable]}` to instead have `}\n#[stable]`
Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustc/lint/builtin.rs src/librustc/session/config.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/context.rs src/librustc_trans/trans/type_.rs src/librustc_typeck/check/_match.rs src/librustdoc/html/format.rs src/libsyntax/std_inject.rs src/libsyntax/util/interner.rs src/test/compile-fail/mut-pattern-mismatched.rs
This is a [breaking-change].
Change
impl<T> Foo<T> {
fn bar<T>(...
to (for example)
impl<T> Foo<T> {
fn bar<U>(...
Per RFC 459.
Closes rust-lang#19390.
Conflicts: src/librustc_typeck/check/wf.rs
…new` instead in the future.)
…atch-projection Conflicts: src/librustc/middle/ty.rs
…-in-structs-issue-20470 Conflicts: src/librustc_trans/trans/expr.rs
…ox::new` instead.)
… as prior two commits.)
Conflicts: src/compiletest/compiletest.rs src/libcollections/lib.rs src/libserialize/lib.rs src/libsyntax/feature_gate.rs
|
r? @nick29581 (rust_highfive has picked a reviewer for you, use r? to override) |
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.