Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations.
BTreeMap's internal Node representation is particularly inefficient at the moment to
make this first implementation easy to reason about and fairly safe. Both collections
are also currently missing some of the tooling specific to sorted collections, which
is planned as future work pending reform of these APIs. General implementation issues
are discussed with TODOs internally
[breaking-change]
Still waiting on compilation/test/bench stuff locally, but the edit-distance on any errors should be very small at this point. This is ready to be reviewed.
Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations.
BTreeMap's internal Node representation is particularly inefficient at the moment to
make this first implementation easy to reason about and fairly safe. Both collections
are also currently missing some of the tooling specific to sorted collections, which
is planned as future work pending reform of these APIs. General implementation issues
are discussed with TODOs internally
Perf results on x86_64 Linux:
test treemap::bench::find_rand_100 ... bench: 76 ns/iter (+/- 4)
test treemap::bench::find_rand_10_000 ... bench: 163 ns/iter (+/- 6)
test treemap::bench::find_seq_100 ... bench: 77 ns/iter (+/- 3)
test treemap::bench::find_seq_10_000 ... bench: 115 ns/iter (+/- 1)
test treemap::bench::insert_rand_100 ... bench: 111 ns/iter (+/- 1)
test treemap::bench::insert_rand_10_000 ... bench: 996 ns/iter (+/- 18)
test treemap::bench::insert_seq_100 ... bench: 486 ns/iter (+/- 20)
test treemap::bench::insert_seq_10_000 ... bench: 800 ns/iter (+/- 15)
test btree::map::bench::find_rand_100 ... bench: 74 ns/iter (+/- 4)
test btree::map::bench::find_rand_10_000 ... bench: 153 ns/iter (+/- 5)
test btree::map::bench::find_seq_100 ... bench: 82 ns/iter (+/- 1)
test btree::map::bench::find_seq_10_000 ... bench: 108 ns/iter (+/- 0)
test btree::map::bench::insert_rand_100 ... bench: 220 ns/iter (+/- 1)
test btree::map::bench::insert_rand_10_000 ... bench: 620 ns/iter (+/- 16)
test btree::map::bench::insert_seq_100 ... bench: 411 ns/iter (+/- 12)
test btree::map::bench::insert_seq_10_000 ... bench: 534 ns/iter (+/- 14)
BTreeMap still has a lot of room for optimization, but it's already beating out TreeMap on most access patterns.
[breaking-change]
The sentence "The new iterator `filter()` produces returns only the elements that that closure returned `true` for:" can be structured as:
"The new iterator `filter()` produces only the elements that that closure returned `true` for:"
or as:
"The new iterator `filter()` returns only the elements that that closure returned `true` for:"
however, not both.
I went with "produces", since it then talks about returning true and having "return" so close together doesn't sound nice.
r @steveklabnik ?
over inherent methods accessible via more autoderefs.
This simplifies the trait matching algorithm. It breaks code like:
impl Foo {
fn foo(self) {
// before this change, this will be called
}
}
impl<'a,'b,'c> Trait for &'a &'b &'c Foo {
fn foo(self) {
// after this change, this will be called
}
}
fn main() {
let x = &(&(&Foo));
x.foo();
}
To explicitly indicate that you wish to call the inherent method, perform
explicit dereferences. For example:
fn main() {
let x = &(&(&Foo));
(***x).foo();
}
Part of #17282.
[breaking-change]
r? @nikomatsakis
over inherent methods accessible via more autoderefs.
This simplifies the trait matching algorithm. It breaks code like:
impl Foo {
fn foo(self) {
// before this change, this will be called
}
}
impl<'a,'b,'c> Trait for &'a &'b &'c Foo {
fn foo(self) {
// after this change, this will be called
}
}
fn main() {
let x = &(&(&Foo));
x.foo();
}
To explicitly indicate that you wish to call the inherent method, perform
explicit dereferences. For example:
fn main() {
let x = &(&(&Foo));
(***x).foo();
}
Part of #17282.
[breaking-change]
This commit is another in the series of vector slice API stabilization. The focus here is the *mutable* slice API.
Largely, this API inherits the stability attributes [previously assigned](rust-lang#16332) to the analogous methods on immutable slides. It also adds comments to a few `unstable` attributes that were previously missing them.
In addition, the commit adds several `_mut` variants of APIs that were missing:
- `init_mut`
- `head_mut`
- `tail_mut`
- `splitn_mut`
- `rsplitn_mut`
Some of the unsafe APIs -- `unsafe_set`, `init_elem`, and `copy_memory` -- were deprecated in favor of working through `as_mut_ptr`, to simplify the API surface.
Due to deprecations, this is a:
[breaking-change]
The tuple serialization logic should be using the tuple-specific emit function. This fixes part of #17158. The JSON encoder already proxies to `emit_seq_elt` when `emit_tuple_arg` is called, so this should have an effect.
This commit is another in the series of vector slice API
stabilization. The focus here is the *mutable* slice API.
Largely, this API inherits the stability attributes [previously
assigned](https://github.com/rust-lang/rust/pull/16332) to the analogous
methods on immutable slides. It also adds comments to a few `unstable`
attributes that were previously missing them.
In addition, the commit adds several `_mut` variants of APIs that were
missing:
- `init_mut`
- `head_mut`
- `tail_mut`
- `splitn_mut`
- `rsplitn_mut`
Some of the unsafe APIs -- `unsafe_set`, `init_elem`, and `copy_memory`
-- were deprecated in favor of working through `as_mut_ptr`, to simplify
the API surface.
Due to deprecations, this is a:
[breaking-change]
Moves the vast majority of builtin bound checking out of type contents and into the trait system.
This is a preliminary step for a lot of follow-on work:
- opt-in builtin types, obviously
- generalized where clauses, because TypeContents has this notion that a type parameter has a single set of builtin kinds, but with where clauses it depends on context
- generalized coherence, because this adds support for recursive trait selection
Unfortunately I wasn't able to completely remove Type Contents from the front-end checking in this PR. It's still used by EUV to decide what gets moved and what doesn't.
r? @pcwalton
Intended to prevent each user to write his own partial_min/max, possibly differing in slight details. @sfackler encouraged to PR this on IRC.
(Let's hope this works... First PR.)
OrdIterator: the doc says that values must implement `PartialOrd`, while the implementation is only for `Ord` values. It looks like this initially got out of sync in 4e1c215. Removed the doc sentence entirely since it seems redundant.
MultiplicativeIterator: Fixed weird sentence.
This is a PR for #16114 and includes to following things:
* Rename `begin_unwind` lang item to `fail_fmt`
* Rename `core::failure::begin_unwind` to `fail_impl`
* Rename `fail_` lang item to `fail`
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree` is part of the complete rewrite in #17334.
The implemented API deviates from the API described in the RFC in two key places:
* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.
This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.
[breaking-change]
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
although this still needs to be done on the rest of the maps, they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree`'s is part of the complete rewrite in #17334.
The implemented API deviates from the API described in the RFC in two key places:
* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.
This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.
[breaking-change]
