in most cases, just the error message changed, but in some cases we
are reporting new errors that OUGHT to have been reported before but
we're overlooked (mostly involving the `'static` bound on `Send`).
- Remove the `for Sized?` bound on `core::ops::FnOnce`, as it takes `self` by value and can never be implemented by an unsized type.
- Add a missing `Sized?` bound to the blanket `core::ops::FnMut` impl, as both `Fn` and `FnMut` are `for Sized?`.
Brief note: This does *not* affect anything in the prelude
Part of #19253
All this does is remove the reexporting of Result and Option from their
respective modules. More core reexports might be removed, but these ones
are the safest to remove since these enums (and their variants) are included in
the prelude.
Depends on https://github.com/rust-lang/rust/pull/19407 which is merged, but might need a new snapshot
[breaking-change]
detect UFCS drop and allow UFCS methods to have explicit type parameters.
Work towards #18875.
Since code could previously call the methods & implement the traits
manually, this is a
[breaking-change]
Closes#19586. Closes#19375.
Brief note: This does *not* affect anything in the prelude
Part of #19253
All this does is remove the reexporting of Result and Option from their
respective modules. More core reexports might be removed, but these ones
are the safest to remove since these enums (and their variants) are included in
the prelude.
[breaking-change]
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
In regards to:
https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729
This commit:
* Changes the #deriving code so that it generates code that utilizes fewer
reexports (in particur Option::\*, Result::\*, and Ordering::\*), which is necessary to
remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized
detect UFCS drop and allow UFCS methods to have explicit type parameters.
Work towards #18875.
Since code could previously call the methods & implement the traits
manually, this is a
[breaking-change]
Closes#19586. Closes#19375.
In regards to:
https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729
This commit:
* Changes the #deriving code so that it generates code that utilizes fewer
reexports (in particur Option::* and Result::*), which is necessary to
remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized
- Remove the `for Sized?` bound on `core::ops::FnOnce`, as it takes
`self` by value and can never be implemented by an unsized type.
- Add a missing `Sized?` bound to the blanket `core::ops::FnMut` impl,
as both `Fn` and `FnMut` are `for Sized?`.
Right now, `DerefMut` is not `for Sized?`, so you can't impl `DerefMut<T> for Foo` where `Foo` is unsized. However, there is no reason that it can't be `for Sized?`, so this pull request fixes the issue.
Closes#19493.
Added the example from [this Reddit thread][1], reworked to be more robust with correct logic (first link skipped the 0th and 1st Fibonacci numbers, second forgot about the last two valid values before overflow). Will yield all Fibonacci numbers sequentially in the range `[0, <u32 as Int>::max_value())`.
If the example is too complicated I can change it to a more naive version, perhaps using signed integers to check for overflow instead of `Option` and `.checked_add()`.
Also reworded the doc comments to clarify the usage and behavior of `Unfold`, as the thread suggested that it wasn't really clear how `Unfold` worked and when one should use it.
This change is in the `core` crate but I based the example on `std` since that's where most readers will find the example. I included a note about `core` for clarity. Edit: removed.
Tested with `rustdoc src/libcore/lib.rs`. Rebased against latest master as of the creation of this PR.
[1]: http://www.reddit.com/r/rust/comments/2ny8r1/a_question_about_loops/cmighu4?context=10000
1. Made small improvements to the docs for checked_sub, checked_mul and checked_div.
2. Updated a confusingly outdated comment for intrinsics, noticed before at <https://stackoverflow.com/questions/23582931/>.
This continues the work @thestinger started in #18885 (which hasn't landed yet, so wait for that to land before landing this one). Instead of adding more methods to `BufReader`, this just allows a `&[u8]` to be used directly as a `Reader`. It also adds an impl of `Writer` for `&mut [u8]`.
Comparison traits have gained an `Rhs` input parameter that defaults to `Self`. And now the comparison operators can be overloaded to work between different types. In particular, this PR allows the following operations (and their commutative versions):
- `&str` == `String` == `CowString`
- `&[A]` == `&mut [B]` == `Vec<C>` == `CowVec<D>` == `[E, ..N]` (for `N` up to 32)
- `&mut A` == `&B` (for `Sized` `A` and `B`)
Where `A`, `B`, `C`, `D`, `E` may be different types that implement `PartialEq`. For example, these comparisons are now valid: `string == "foo"`, and `vec_of_strings == ["Hello", "world"]`.
[breaking-change]s
Since the `==` may now work on different types, operations that relied on the old "same type restriction" to drive type inference, will need to be type annotated. These are the most common fallout cases:
- `some_vec == some_iter.collect()`: `collect` needs to be type annotated: `collect::<Vec<_>>()`
- `slice == &[a, b, c]`: RHS doesn't get coerced to an slice, use an array instead `[a, b, c]`
- `lhs == []`: Change expression to `lhs.is_empty()`
- `lhs == some_generic_function()`: Type annotate the RHS as necessary
cc #19148
r? @aturon
