| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Conflicts:
src/test/compile-fail/coherence-impls-copy.rs
|
|
Feature-gate unsigned unary negate.
Discussed in weekly meeting here: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-03-31.md#feature-gate--expr
and also in the internals thread here: http://internals.rust-lang.org/t/forbid-unsigned-integer/752
|
|
Namely, the special case treatment for `div`/`rem` is only applicable
to signed integer values.
Clearly RFC 1027 would have saved us here! ;)
|
|
|
|
|
|
This commit is an implementation of [RFC 979][rfc] which changes the meaning of
the count parameter to the `splitn` function on strings and slices. The
parameter now means the number of items that are returned from the iterator, not
the number of splits that are made.
[rfc]: https://github.com/rust-lang/rfcs/pull/979
Closes #23911
[breaking-change]
|
|
This commit is an implementation of [RFC 979][rfc] which changes the meaning of
the count parameter to the `splitn` function on strings and slices. The
parameter now means the number of items that are returned from the iterator, not
the number of splits that are made.
[rfc]: https://github.com/rust-lang/rfcs/pull/979
Closes #23911
[breaking-change]
|
|
Recent numerics stabilization removed the inherent `min_value` and
`max_value` methods from integer types, assuming that the module-level
constants would suffice. However, that failed to account for the use
case in FFI code when dealing with integer type aliases.
This commit reintroduces the methods as `#[stable]`, since this is
essential functionality for 1.0.
It's unfortunate to freeze these as methods, but when we can provide
inherent associated constants these methods can be deprecated.
r? @sfackler
cc @alexcrichton
|
|
This PR implements rust-lang/rfcs#1023. In the process it fixes #23086 and #23516. A few impls in libcore had to be updated, but the impact is generally pretty minimal. Most of the fallout is in the tests that probed the limits of today's coherence.
I tested and we were able to build the most popular crates along with iron (modulo errors around errors being sendable).
Fixes #23918.
|
|
Recent numerics stabilization removed the inherent `min_value` and
`max_value` methods from integer types, assuming that the module-level
constants would suffice. However, that failed to account for the use
case in FFI code when dealing with integer type aliases.
This commit reintroduces the methods as `#[stable]`, since this is
essential functionality for 1.0.
It's unfortunate to freeze these as methods, but when we can provide
inherent associated constants these methods can be deprecated.
|
|
sidesteps a coherence difficulty where `liballoc` had to prove that
`&str: !Error`, which didn't involve any local types.
|
|
|
|
Fixes #22914
Said issue was mostly fixed, as there wasn't any examples when it was initially posted. This is mostly just some re-wording of some things and some cleanup
|
|
The primary purpose of this PR is to add blanket impls for the `Fn` traits of the following (simplified) form:
impl<F:Fn> Fn for &F
impl<F:FnMut> FnMut for &mut F
However, this wound up requiring two changes:
1. A slight hack so that `x()` where `x: &mut F` is translated to `FnMut::call_mut(&mut *x, ())` vs `FnMut::call_mut(&mut x, ())`. This is achieved by just autoderef'ing one time when calling something whose type is `&F` or `&mut F`.
2. Making the infinite recursion test in trait matching a bit more tailored. This involves adding a notion of "matching" types that looks to see if types are potentially unifiable (it's an approximation).
The PR also includes various small refactorings to the inference code that are aimed at moving the unification and other code into a library (I've got that particular change in a branch, these changes just lead the way there by removing unnecessary dependencies between the compiler and the more general unification code).
Note that per rust-lang/rfcs#1023, adding impls like these would be a breaking change in the future.
cc @japaric
cc @alexcrichton
cc @aturon
Fixes #23015.
|
|
|
|
|
|
|
|
|
|
`Fn` traits are considered fundamental, along with `Box` (though that is
mostly for show; the real type is `~T` in the compiler).
|
|
|
|
This means passing in e.g. a `Vec<u8>` or `String` will work as
intended, rather than deref-ing to `&mut [u8]` or `&mut str`.
[breaking-change]
Closes #23768
|
|
const_eval : add overflow-checking for {`+`, `-`, `*`, `/`, `<<`, `>>`}.
One tricky detail here: There is some duplication of labor between `rustc::middle::const_eval` and `rustc_trans::trans::consts`. It might be good to explore ways to try to factor out the common structure to the two passes (by abstracting over the particular value-representation used in the compile-time interpreter).
----
Update: Rebased atop #23841
Fix #22531
Fix #23030
Fix #23221
Fix #23235
|
|
|
|
|
|
Fixes #22914
|
|
Conflicts:
src/libcore/iter.rs
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Closes #19470
[breaking-change]
|
|
* The `io::Seek` trait.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
r? @alexcrichton
|
|
|
|
Conflicts:
src/libcollectionstest/fmt.rs
src/libcollectionstest/lib.rs
src/libcollectionstest/str.rs
src/libcore/error.rs
src/libstd/fs.rs
src/libstd/io/cursor.rs
src/libstd/os.rs
src/libstd/process.rs
src/libtest/lib.rs
src/test/run-pass-fulldeps/compiler-calls.rs
|
|
Conflicts:
src/libcore/error.rs
|
|
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
r? @alexcrichton
|
|
|
|
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
|
|
|
|
`min`-like functions now return the leftmost element/input for equal elements.
`max`-like return the rightmost.
Closes #23687.
cc @HeroesGrave, @aturon, @alexcrichton
|
|
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
[breaking-change]
|
|
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
cc #19470
[breaking-change]
|
|
Fixes #23851
|
|
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
|
|
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes #22985
Closes #21069
[breaking-change]
r? @alexcrichton
|
|
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes #22985
Closes #21069
[breaking-change]
r? @alexcrichton
|
|
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes #22985
Closes #21069
[breaking-change]
|
|
|
|
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes #22890
[breaking-change]
|
|
Based on the comment from @apasel422 in https://github.com/rust-lang/rust/pull/23791#issuecomment-87095298.
Where @apasel422 proposed
```
Moves the value out of the option if it is `Some`, or panics if it is `None`.
```
I include in this PR the version
```
Moves the value `v` out of the `Option` if it is `Some(v)`, or panics if it is `None`.
```
which
- is a little bit more precise about what value is actually returned
- uses `Option` over just "option" in the part `out of the [Option]
r? @steveklabnik, @apasel422
|
|
To not use `old_io` and `os`, which are deprecated. Since there is no more `MemoryMap` used byte parsing instead to generate the second potential error.
You can see the code working fine [here](http://is.gd/4g0wwp) on the PlayPen.
|
|
This removes the FromError trait, since it can now be expressed using
the new convert::Into trait. All implementations of FromError<E> where
changed to From<E>, and `try!` was changed to use From::from instead.
Because this removes FromError, it is a breaking change, but fixing it
simply requires changing the words `FromError` to `From`, and
`from_error` to `from`.
[breaking-change]
|
