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.
Implements [RFC 486](https://github.com/rust-lang/rfcs/pull/486). Fixes#19908.
* Rename `to_ascii_{lower,upper}` to `to_ascii_{lower,upper}case`, per #14401
* Remove the `Ascii` type and associated traits: `AsciiCast`, `OwnedAsciiCast`, `AsciiStr`, `IntoBytes`, and `IntoString`.
* As a replacement, add `.is_ascii()` to `AsciiExt`, and implement `AsciiExt` for `u8` and `char`.
[breaking-change]
closes#19141closes#20193closes#20228
---
Currently whenever we encounter `let f = || {/* */}`, we *always* type check the RHS as a *boxed* closure. This is wrong when the RHS is `move || {/* */}` (because boxed closures can't capture by value) and generates all sort of badness during trans (see issues above). What we *should* do is always type check `move || {/* */}` as an *unboxed* closure, but ~~I *think* (haven't tried)~~ (2) this is not feasible right now because we have a limited form of kind (`Fn` vs `FnMut` vs `FnOnce`) inference that only works when there is an expected type (1).
In this PR, I've chosen to generate a type error whenever `let f = move || {/* */}` is encountered. The error asks the user to annotate the kind of the unboxed closure (e.g. `move |:| {/* */}`). Once annotated, the compiler will type check the RHS as an unboxed closure which is what the user wants.
r? @nikomatsakis
(1) AIUI it only triggers in this scenario:
``` rust
fn is_uc<F>(_: F) where F: FnOnce() {}
fn main() {
is_uc(|| {}); // type checked as unboxed closure with kind `FnOnce`
}
```
(2) I checked, and it's not possible because `check_unboxed_closure` expects a `kind` argument, but we can't supply that argument in this case (i.e. `let f = || {}`, what's the kind?). We could force the `FnOnce` kind in that case, but that's ad hoc. We should try to infer the kind depending on how the closure is used afterwards, but there is no inference mechanism to do that (at least, not right now).
More work on opt-in built in traits. `Send` and `Sync` are not opt-in, `OwnedPtr` renamed to `UniquePtr` and the `Send` and `Sync` traits are now unsafe.
NOTE: This likely needs to be rebased on top of the yet-to-land snapshot.
r? @nikomatsakis
cc #13231
