Part of #19253
I would have removed this public reexport in #19842, but #19812 hadn't merged (and snapshotted) at the time
In #19407, I changed the codebase to stop utilizing this reexport
[breaking-change]
This patch marks `clone` stable, as well as the `Clone` trait, but
leaves `clone_from` unstable. The latter will be decided by the beta.
The patch also marks most manual implementations of `Clone` as stable,
except where the APIs are otherwise deprecated or where there is
uncertainty about providing `Clone`.
r? @alexcrichton
This patch finalizes stabilization for the `cell` module, settling on
the current names `Cell`, `RefCell`, `UnsafeCell`, `Ref` and `RefMut`.
While we had considered improving these names, no one was able to
produce a truly compelling alternative.
There is one substantive change here: the `get` method of `UnsafeSell`
is now marked `unsafe`. Merely getting a raw pointer to the contents is
not, by itself, an unsafe operation. (Consider that you can always
safely turn a reference into a raw pointer, and that raw pointer may
then be aliased by subsequent references.)
r? @alexcrichton
This small patch stabilizes the names of all integer modules (including
`int` and `uint`) and the `MIN` and `MAX` constants. The `BITS` and
`BYTES` constants are left unstable for now.
r? @alexcrichton
This commit modifies rustdoc to not require these empty modules to be public in
the standard library. The modules still remain as a location to attach
documentation to, but the modules themselves are now private (don't have to
commit to an API). The documentation for the standard library now shows all of
the primitive types on the main index page.
This commit, like the second pass of `Option`, largely just stablizes the
existing functionality after renaming a few iterators.
The specific actions taken were:
* The `Ok` and `Err` variants were marked `#[stable]` as the stability
inheritance was since removed.
* The `as_mut` method is now stable.
* The `map` method is now stable
* The `map_err` method is now stable
* The `iter`, `iter_mut`, and `into_iter` methods now returned structures named
after the method of iteration. The methods are also now all stable.
* The `and_then` method is now stable.
* The `or_else` method is now stable.
* The `unwrap` family of functions are now all stable: `unwrap_or`,
`unwrap_or_else`, `unwrap`, and `unwrap_err`.
There is a possible open extension to `Result::{and, and_then}` to make the
return type further generic over `FromError` (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.
This patch marks `clone` stable, as well as the `Clone` trait, but
leaves `clone_from` unstable. The latter will be decided by the beta.
The patch also marks most manual implementations of `Clone` as stable,
except where the APIs are otherwise deprecated or where there is
uncertainty about providing `Clone`.
This patch finalizes stabilization for the `cell` module, settling on
the current names `Cell`, `RefCell`, `UnsafeCell`, `Ref` and `RefMut`.
While we had considered improving these names, no one was able to
produce a truly compelling alternative.
There is one substantive change here: the `get` method of `UnsafeSell`
is now marked `unsafe`. Merely getting a raw pointer to the contents is
not, by itself, an unsafe operation. (Consider that you can always
safely turn a reference into a raw pointer, and that raw pointer may
then be aliased by subsequent references.)
This small patch stabilizes the names of all integer modules (including
`int` and `uint`) and the `MIN` and `MAX` constants. The `BITS` and
`BYTES` constants are left unstable for now.
The `is_power_of_two()` method of the `UnsignedInt` trait currently returns `true` for `self == 0`. Zero is not a power of two, assuming an integral exponent `k >= 0`. I've therefore moved this functionality to the new method `is_power_of_two_or_zero()` and reformed `is_power_of_two()` to return false for `self == 0`.
To illustrate the usefulness of the existence of both functions, consider `HashMap`. Its capacity must be zero or a power of two; conversely, it also requires a (non-zero) power of two for key and val alignment.
Also, added a small amount of documentation regarding #18604.
This commit, like the second pass of `Option`, largely just stablizes the
existing functionality after renaming a few iterators.
The specific actions taken were:
* The `Ok` and `Err` variants were marked `#[stable]` as the stability
inheritance was since removed.
* The `as_mut` method is now stable.
* The `map` method is now stable
* The `map_err` method is now stable
* The `iter`, `iter_mut`, and `into_iter` methods now returned structures named
after the method of iteration. The methods are also now all stable.
* The `and_then` method is now stable.
* The `or_else` method is now stable.
* The `unwrap` family of functions are now all stable: `unwrap_or`,
`unwrap_or_else`, `unwrap`, and `unwrap_err`.
There is a possible open extension to `Result::{and, and_then}` to make the
return type further generic over `FromError` (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.
This commit modifies rustdoc to not require these empty modules to be public in
the standard library. The modules still remain as a location to attach
documentation to, but the modules themselves are now private (don't have to
commit to an API). The documentation for the standard library now shows all of
the primitive types on the main index page.
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
In US english, "that" is used in restrictive clauses in place of
"which", and often affects the meaning of sentences.
In UK english and many dialects, no distinction is
made.
While Rust devs want to avoid unproductive pedanticism, it is worth at
least being uniform in documentation such as:
http://doc.rust-lang.org/std/iter/index.html
and also in cases where correct usage of US english clarifies the
sentence.
This commit takes a second pass through the `std::option` module to fully
stabilize any lingering methods inside of it.
These items were made stable as-is
* Some
* None
* as_mut
* expect
* unwrap
* unwrap_or
* unwrap_or_else
* map
* map_or
* map_or_else
* and_then
* or_else
* unwrap_or_default
* Default implementation
* FromIterator implementation
* Copy implementation
These items were made stable with modifications
* iter - now returns a struct called Iter
* iter_mut - now returns a struct called IterMut
* into_iter - now returns a struct called IntoIter, Clone is never implemented
This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
`IntoIter` no longer implements the `Clone` trait.
These items were explicitly not stabilized
* as_slice - waiting on indexing conventions
* as_mut_slice - waiting on conventions with as_slice as well
* cloned - the API was still just recently added
* ok_or - API remains experimental
* ok_or_else - API remains experimental
[breaking-change]
closes#12677 (cc @Valloric)
cc #15294
r? @aturon / @alexcrichton
(Because of #19358 I had to move the struct bounds from the `where` clause into the parameter list)
per rfc 459
cc https://github.com/rust-lang/rust/issues/19390
One question is: should we start by warning, and only switch to hard error later? I think we discussed something like this in the meeting.
r? @alexcrichton
This commit performs a second pass stabilization of the `std::default` module.
The module was already marked `#[stable]`, and the inheritance of `#[stable]`
was removed since this attribute was applied. This commit adds the `#[stable]`
attribute to the trait definition and one method name, along with all
implementations found in the standard distribution.
This commit takes a second pass through the `std::mem` module for stabilization.
The only remaining non-stable items in this module were `forget`, `transmute`,
`copy_lifetime`, and `copy_lifetime_mut`.
The `forget` and `transmute` intrinsics themselves were marked `#[stable]` to
propgate into the `core::mem` module so they would be marked stable.
The `copy_lifetime` functions were left `unstable`, but `Sized?` annotations
were added to the parameters to allow more general use with DSTs.
The `size_of_val`, `min_align_of_val`, and `align_of_val` functions would like
to grow `Sized?` bounds, but this is a backwards compatible change that
currently ICEs the compiler, so this change was not made at this time.
Finally, the module itself was declared `#![stable]` in this pass.
This commit collapses the various prelude traits for slices into just one trait:
* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt
- The following operator traits now take their arguments by value: `Add`, `Sub`, `Mul`, `Div`, `Rem`, `BitAnd`, `BitOr`, `BitXor`, `Shl`, `Shr`. This breaks all existing implementations of these traits.
- The binary operation `a OP b` now "desugars" to `OpTrait::op_method(a, b)` and consumes both arguments.
- `String` and `Vec` addition have been changed to reuse the LHS owned value, and to avoid internal cloning. Only the following asymmetric operations are available: `String + &str` and `Vec<T> + &[T]`, which are now a short-hand for the "append" operation.
[breaking-change]
---
This passes `make check` locally. I haven't touch the unary operators in this PR, but converting them to by value should be very similar to this PR. I can work on them after this gets the thumbs up.
@nikomatsakis r? the compiler changes
@aturon r? the library changes. I think the only controversial bit is the semantic change of the `Vec`/`String` `Add` implementation.
cc #19148
