We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or
`unsafe extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095Closes#24119
cc #24014
r? @alexcrichton
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095
cc #24014
In addition to being nicer, this also allows you to use `sum` and `product` for
iterators yielding custom types aside from the standard integers.
Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this
is a breaking change.
[breaking-change]
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or `unsafe
extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
* Fix broken \"module-level documentation\" link on the [`trait Any` docs](http://doc.rust-lang.org/std/any/trait.Any.html) and related broken markup on the [`std::any` docs](http://doc.rust-lang.org/std/any/index.html).
* Remove an outdated or incorrect notice in the `BufRead::lines` docs. There is no such `read_string` function, and `lines` never returns an error.
r? @steveklabnik
This adds the missing methods and turns `str::pattern` in a user facing module, as per RFC.
This also contains some big internal refactorings:
- string iterator pairs are implemented with a central macro to reduce redundancy
- Moved all tests from `coretest::str` into `collectionstest::str` and left a note to prevent the two sets of tests drifting apart further.
See https://github.com/rust-lang/rust/issues/22477
- Added missing reverse versions of methods
- Added [r]matches()
- Generated the string pattern iterators with a macro
- Added where bounds to the methods returning reverse iterators
for better error messages.
There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.
r? @pnkfelix
Fixes#22806 (since such traits would no longer exist)
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
These constants are small and can fit even in `u8`, but semantically they have type `usize` because they denote sizes and are almost always used in `usize` context. The change of their type to `u32` during the integer audit led only to the large amount of `as usize` noise (see the second commit, which removes this noise).
This is a minor [breaking-change] to an unstable interface.
r? @aturon
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/979Closes#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/979Closes#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.
