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.
Names of structs, enums, traits, type aliases and type parameters (i.e. all identifiers that can be used as full paths in type position) are not allowed to match the names of primitive types.
See #20427 for more information.
This is a minor [breaking-change]
borrowck: Prevent partial reinitialization of uninitialized structures
This is a pnkfelix-swiped squash of #22079, which was a rebase and revision of #18963Fixes#18571.
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
This resolves a number of bugs that trigger stack overflows or other cyclic errors.
r? @nick29581 (it is based on work that you started)
f? @jroesch (also based on your branch)
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.
