This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
This commit is the standard API stabilization commit for the 1.6 release cycle.
The list of issues and APIs below have all been through their cycle-long FCP and
the libs team decisions are listed below
Stabilized APIs
* `Read::read_exact`
* `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`)
* libcore -- this was a bit of a nuanced stabilization, the crate itself is now
marked as `#[stable]` and the methods appearing via traits for primitives like
`char` and `str` are now also marked as stable. Note that the extension traits
themeselves are marked as unstable as they're imported via the prelude. The
`try!` macro was also moved from the standard library into libcore to have the
same interface. Otherwise the functions all have copied stability from the
standard library now.
* The `#![no_std]` attribute
* `fs::DirBuilder`
* `fs::DirBuilder::new`
* `fs::DirBuilder::recursive`
* `fs::DirBuilder::create`
* `os::unix::fs::DirBuilderExt`
* `os::unix::fs::DirBuilderExt::mode`
* `vec::Drain`
* `vec::Vec::drain`
* `string::Drain`
* `string::String::drain`
* `vec_deque::Drain`
* `vec_deque::VecDeque::drain`
* `collections::hash_map::Drain`
* `collections::hash_map::HashMap::drain`
* `collections::hash_set::Drain`
* `collections::hash_set::HashSet::drain`
* `collections::binary_heap::Drain`
* `collections::binary_heap::BinaryHeap::drain`
* `Vec::extend_from_slice` (renamed from `push_all`)
* `Mutex::get_mut`
* `Mutex::into_inner`
* `RwLock::get_mut`
* `RwLock::into_inner`
* `Iterator::min_by_key` (renamed from `min_by`)
* `Iterator::max_by_key` (renamed from `max_by`)
Deprecated APIs
* `ErrorKind::UnexpectedEOF` (renamed to `UnexpectedEof`)
* `OsString::from_bytes`
* `OsStr::to_cstring`
* `OsStr::to_bytes`
* `fs::walk_dir` and `fs::WalkDir`
* `path::Components::peek`
* `slice::bytes::MutableByteVector`
* `slice::bytes::copy_memory`
* `Vec::push_all` (renamed to `extend_from_slice`)
* `Duration::span`
* `IpAddr`
* `SocketAddr::ip`
* `Read::tee`
* `io::Tee`
* `Write::broadcast`
* `io::Broadcast`
* `Iterator::min_by` (renamed to `min_by_key`)
* `Iterator::max_by` (renamed to `max_by_key`)
* `net::lookup_addr`
New APIs (still unstable)
* `<[T]>::sort_by_key` (added to mirror `min_by_key`)
Closes#27585Closes#27704Closes#27707Closes#27710Closes#27711Closes#27727Closes#27740Closes#27744Closes#27799Closes#27801
cc #27801 (doesn't close as `Chars` is still unstable)
Closes#28968
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```rust
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.
Did this alphabetically, so I didn't see [how `std` was doing things](https://dxr.mozilla.org/rust/source/src/libstd/lib.rs#215) till I was nearly finished. If you prefer to add crate-level-whitelists like std instead of test-level, I can rebase with that strategy.
A number of these commits can probably be dropped as the crates don't have much to test, and are deprecated. Let me know which if any to drop! (can also squash after review if desired)
r? @steveklabnik
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
`Rc::try_unwrap` and `Rc::make_mut` are stable since 1.4.0, but the example code still has `#![feature(rc_unique)]`. Ideally the stable and beta docs would be updated, but I don't think that's possible...
Before this patch `reserve` function allocated twice as requested
amount elements (not twice as capacity). It leaded to unnecessary
excessive memory usage in scenarios like this:
```
let mut v = Vec::new();
v.push(17);
v.extend(0..10);
println!("{}", v.capacity());
```
`Vec` allocated 22 elements, while it could allocate just 11.
`reserve` function must have a property of keeping `push` operation
cost (which calls `reserve`) `O(1)`. To achieve this `reserve` must
exponentialy grow its capacity when it does reallocation.
There's better strategy to implement `reserve`:
```
let new_capacity = max(current_capacity * 2, requested_capacity);
```
This strategy still guarantees that capacity grows at `O(1)` with
`reserve`, and fixes the issue with `extend`.
Patch imlpements this strategy.
Before this patch `reserve` function allocated twice as requested
amount elements (not twice as capacity). It leaded to unnecessary
excessive memory usage in scenarios like this:
```
let mut v = Vec::new();
v.push(17);
v.extend(0..10);
println!("{}", v.capacity());
```
`Vec` allocated 22 elements, while it could allocate just 11.
`reserve` function must have a property of keeping `push` operation
cost (which calls `reserve`) `O(1)`. To achieve this `reserve` must
exponentialy grow its capacity when it does reallocation.
There's better strategy to implement `reserve`:
```
let new_capacity = max(current_capacity * 2, requested_capacity);
```
This strategy still guarantees that capacity grows at `O(1)` with
`reserve`, and fixes the issue with `extend`.
Patch imlpements this strategy.
This change has two consequences:
1. It makes `Arc<T>` and `Rc<T>` covariant in `T`.
2. It causes the compiler to reject code that was unsound with respect
to dropck. See compile-fail/issue-29106.rs for an example of code that
no longer compiles. Because of this, this is a [breaking-change].
Fixes#29037.
Fixes#29106.
The text says it's a vector of floats, but the code actually uses a vector of integers. The type of the Vec doesn't really matter, so I just cut it from the text.
I needed it in `RawVec`, `Vec`, and `TypedArena` for `rustc` to
bootstrap; but of course that alone was not sufficient for `make
check`.
Later I added `unsafe_destructor_blind_to_params` to collections, in
particular `LinkedList` and `RawTable` (the backing representation for
`HashMap` and `HashSet`), to get the regression tests exercising
cyclic structure from PR #27185 building.
----
Note that the feature is `dropck_parametricity` (which is not the same
as the attribute's name). We will almost certainly vary our strategy
here in the future, so it makes some sense to have a not-as-ugly name
for the feature gate. (The attribute name was deliberately selected to
be ugly looking.)
These common traits were left off originally by accident from these smart
pointers, and a past attempt (#26008) to add them was later reverted (#26160)
due to unexpected breakge (#26096) occurring. The specific breakage in worry is
the meaning of this return value changed:
let a: Box<Option<T>> = ...;
a.as_ref()
Currently this returns `Option<&T>` but after this change it will return
`&Option<T>` because the `AsRef::as_ref` method shares the same name as
`Option::as_ref`. A [crater report][crater] of this change, however, has shown
that the fallout of this change is quite minimal. These trait implementations
are "the right impls to add" to these smart pointers and would enable various
generalizations such as those in #27197.
[crater]: https://gist.github.com/anonymous/0ba4c3512b07641c0f99
This commit is a breaking change for the above reasons mentioned, and the
mitigation strategies look like any of:
Option::as_ref(&a)
a.as_ref().as_ref()
(*a).as_ref()
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:
* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").
After this commit, the remaining large unstable functionality specific to libcore is:
* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823) and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?
I believe other unstable pieces are not isolated to just libcore but also affect the standard library.
cc #27701
