Fixes#22047
`Range<u64>` and `Range<i64>` may be longer than usize::MAX on 32-bit
platforms, and thus they cannot fulfill the protocol for
ExactSizeIterator. We don't want a nonobvious platform dependency in
basic iterator traits, so the trait impl is removed.
The logic of this change assumes that usize is at least 32-bit.
This is technically a breaking change; note that `Range<usize>` and
`Range<isize>` are always ExactSizeIterators.
[breaking-change]
Add `#[rustc_error]` annotation, which causes trans to signal an error
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
r? @pnkfelix
Added all active features to the list in reference.md.
Added a second note about keeping the reference.md list up-to-date to the bottom of the list, since not everyone (including me) reads the big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in alphabetical order.
Re-tag `slicing_syntax` as `Accepted`.
Rollup merge (373cbab5b0) of PR #20723
accidentally reverted a portion of commit
8327bcc167 which shifted
`slicing_syntax` from Active to Accepted.
While having a look at the Rust book I found this tiny error. In my opinion this if should be all lowercase, because it follows a colon, but I am no native speaker, so I am probably wrong. Also it is a very tiny change, so feel free to include it in any bigger documentation patch.
Removes the link to the rust-dev mailing list in the bug report submission page and also adds the address of the IRC server (`irc.mozilla.org`). Addresses #22249.
This overhauls the very meager docs that currently exist to clarify
various understandable confusions that I've noticed, e.g. people look in
`std::raw` for the "real" types of slices like `&[T]`, or think that
`Slice<T>` refers to `[T]` (fixes#22214).
This patch takes the liberty of offering some "style" guidance around
`raw::Slice`, since there's more restricted ways to duplicate all
functionality connected to it: `std::slice::from_raw_parts{,_mut}` for
construction and `.as_{,mut_}ptr` & `.len` for deconstruction.
It also deprecates the `std::raw::Closure` type which is now useless for
non-type-erased closures, and replaced by `TraitObject` for `&Fn`, `&mut
FnMut` etc, so I guess it should be called a:
[breaking-change]
This is super black magic internals at the moment, but having it
somewhere semi-public seems good. The current versions weren't being
rendered, and they'll be useful for some people.
Fixes#21281
r? @nikomatsakis @kmcallister
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes#22137
Per [RFC 579](https://github.com/rust-lang/rfcs/pull/579), this commit
adds a new `std::process` module. This module is largely based on the
existing `std::old_io::process` module, but refactors the API to use
`OsStr` and other new standards set out by IO reform.
The existing module is not yet deprecated, to allow for the new API to
get a bit of testing before a mass migration to it.
Per [RFC 579](https://github.com/rust-lang/rfcs/pull/579), this commit
adds a new `std::process` module. This module is largely based on the
existing `std::old_io::process` module, but refactors the API to use
`OsStr` and other new standards set out by IO reform.
The existing module is not yet deprecated, to allow for the new API to
get a bit of testing before a mass migration to it.
the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).
use an alternate construction in order to keep the semantic.
Replaced outdated use of the `range(start, end)` function where appropriate with `start..end`, and tweaked the examples to compile and run with the latest rust. I also fixed two periphery compile issues in reference.md which were occluding whether there were any new errors created by these changes.
The default implementation of .repr() will call conveniently call
transmute_copy which should be appropriate for all implementors, but is
memory unsafe if used wrong.
Fixes#22260
You need to use `unsafe impl` to implement the Repr trait now.
[breaking-change]
This overhauls the very meager docs that currently exist to clarify
various understandable confusions that I've noticed, e.g. people look in
`std::raw` for the "real" types of slices like `&[T]`, or think that
`Slice<T>` refers to `[T]` (fixes#22214).
This patch takes the liberty of offering some "style" guidance around
`raw::Slice`, since there's more restricted ways to duplicate all
functionality connected to it: `std::slice::from_raw_parts{,_mut}` for
construction and `.as_{,mut_}ptr` & `.len` for deconstruction.
It also deprecates the `std::raw::Closure` type which is now useless for
non-type-erased closures, and replaced by `TraitObject` for `&Fn`, `&mut
FnMut` etc, so I guess it should be called a:
[breaking-change]
This PR is an optimization of the `FromIterator` implementation of `Vec`
Benchmark: https://gist.github.com/alexcrichton/03d666159a28a80e7c70
Before:
test macro_repeat1 ... bench: 57 ns/iter (+/- 1)
test macro_repeat2 ... bench: 56 ns/iter (+/- 1)
test map_clone1 ... bench: 828 ns/iter (+/- 13)
test map_clone2 ... bench: 828 ns/iter (+/- 8)
test repeat1 ... bench: 1104 ns/iter (+/- 10)
test repeat2 ... bench: 1106 ns/iter (+/- 11)
After:
test macro_repeat1 ... bench: 75 ns/iter (+/- 21)
test macro_repeat2 ... bench: 59 ns/iter (+/- 31)
test map_clone1 ... bench: 34 ns/iter (+/- 22)
test map_clone2 ... bench: 52 ns/iter (+/- 21)
test repeat1 ... bench: 34 ns/iter (+/- 11)
test repeat2 ... bench: 33 ns/iter (+/- 12)
The idea behind this optimization is to avoid all bounds checks for space
already allocated into the vector. This may involve running the iterator twice,
but the first run of the iterator should be optimizable to a memcpy or memset if
possible.
The same treatment can in theory be applied to `Vec::extend` but the benchmarks
for that currently get *worse* if the change is applied. This appears to be some
LLVM optimizations going awry but it's seems prudent to land at least the
`collect` portion beforehand.
