Closes#19949 and rust-lang/rfcs#428
[breaking change]
If you have traits used with objects with static methods, you'll need to move
the static methods to a different trait.
The first six commits are from an earlier PR (#19858) and have already been reviewed. This PR makes an awful hack in the compiler to accommodate slices both natively and in the index a range form. After a snapshot we can hopefully add the new Index impls and then we can remove these awful hacks.
r? @nikomatsakis (or anyone who knows the compiler, really)
[breaking-change]
The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.
These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.
Closes#20096
This stabilizes most methods on `&str` working with patterns in a way that is forwards-compatible with a generic string pattern matching API:
- Methods that are using the primary name for their operation are marked as `#[stable]`, as they can be upgraded to a full `Pattern` API later without existing code breaking. Example: `contains(&str)`
- Methods that are using a more specific name in order to not clash with the primary one are marked as `#[unstable]`, as they will likely be removed once their functionality is merged into the primary one. Example: `contains_char<C: CharEq>(C)`
- The method docs got changed to consistently refer to the pattern types as a pattern.
- Methods whose names do not match in the context of the more generic API got renamed. Example: `trim_chars -> trim_matches`
Additionally, all methods returning iterators got changed to return unique new types with changed names in accordance with the new naming guidelines.
See also https://github.com/rust-lang/rfcs/pull/528
Due to some deprecations and type changes, this is a
[breaking-change]
This takes building `librustc/lib.rs` from using 696 MB to 588 (`rustc --no-trans`), and 1.99 GB to 1.87 (`rustc -O`). It also reduces `sty` down to 32 bytes on platforms with 64-bit pointers, at the expense of some more side-tables in `ctxt`. I'm sure there's more gains to be had from reducing the size of the side tables (e.g. by making the actual things they're storing smaller).
r? @nikomatsakis
This cuts memory use dramatically from the previous commit, and reduces
use overall. E.g. the memory usage of `rustc -O librustc/lib.rs` seems
to drop 100MB from 1.98GB to 1.88GB (on one run anyway).
This extends the nullable enum opt to traverse beyond just the first level to find possible fields to use as the discriminant. So now, it'll work through structs, tuples, and fixed sized arrays. This also introduces a new lang item, NonZero, that you can use to wrap raw pointers or integral types to indicate to rustc that the underlying value is known to never be 0/NULL. We then use this in Vec, Rc and Arc to have them also benefit from the nullable enum opt.
As per https://github.com/rust-lang/rfcs/pull/499 NonZero is not exposed via the `libstd` facade.
```
x86_64 Linux:
T Option<T> (Before) Option<T> (After)
----------------------------------------------------------------------------------
Vec<int> 24 32 24
String 24 32 24
Rc<int> 8 16 8
Arc<int> 8 16 8
[Box<int>, ..2] 16 24 16
(String, uint) 32 40 32
```
Fixes#19419.
Fixes#13194.
Fixes#9378.
Fixes#7576.
Using the current directory may not always be appropriate, for example in
the case where it will unnecessarily trigger a backup to be made.
The only risk with this change is that systems might not have a mktemp.
I am not aware of such a system, but have not tested on Windows. It is
working on a basic Ubuntu and OS X installation.
These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.
Closes#20096
This PR deprecates the `DList::ListInsertion` trait, in accordance with rust-lang/rfcs#509. The functions which were previously part of the ListInsertion impl for `DList::IterMut` have been moved to be inherent methods on the iterator itself, and appropriate doctests have been added.
We have the technology: no longer do you need to write closures to use `format_args!`.
This is a `[breaking-change]`, as it forces you to clean up old hacks - if you had code like this:
```rust
format_args!(fmt::format, "{} {} {}", a, b, c)
format_args!(|args| { w.write_fmt(args) }, "{} {} {}", x, y, z)
```
change it to this:
```rust
fmt::format(format_args!("{} {} {}", a, b, c))
w.write_fmt(format_args!("{} {} {}", x, y, z))
```
To allow them to be called with `format_args!(...)` directly, several functions were modified to
take `fmt::Arguments` by value instead of by reference. Also, `fmt::Arguments` derives `Copy`
now in order to preserve all usecases that were previously possible.
