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
Since we don’t have Deprecated stability level anymore, the only other source of information is
deprecated-since version, which conveniently to us, only exists if the symbol is deprecated.
Fixes#21789
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
`cp -a` is a GNU extension. Use an alternate combinaison of POSIX options
(`-PRp`) that do nearly the same.
The difference is `-a` will preserve context, links and xattr attributes,
whereas `-p` not. But as we use it only for copy a file, there is no
difference in the current context.
`PathBuf` does implement `Hash`, but `Path` doesn't. This makes it
annoying if you have a `HashMap` with `PathBuf`s as keys, because
it means you have to convert a `Path` into a `PathBuf` and get a
reference to it simply to perform operations on the `HashMap`!
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]
It's not clear what this means, because a macro in item position can expand to
zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect,
which seems quite unintended.
Fixes#18317.
Fixes#14660.
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.
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]
