Stabilize more APIs for the 1.20.0 release
In addition to the few stabilizations that have already landed, this cleans up the remaining APIs that are in `final-comment-period` right now to be stable by the 1.20.0 release
Make the "main" constructors of NonZero/Shared/Unique return Option
Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441.
This is a breaking change to unstable APIs.
The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts.
In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
The docs for the `compiler_builtins_lib` library feature were removed
in #42899. But, though the `compiler_builtins` library has been
migrated out-of-tree, the feature remains, and is needed to use the
stand-alone crate. We reintroduce the docs for the feature, and add a
reference to them when describing how to create a `no_std` executable.
Switch to rust-lang-nursery/compiler-builtins
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
Add `Iterator::for_each`
This works like a `for` loop in functional style, applying a closure to
every item in the `Iterator`. It doesn't allow `break`/`continue` like
a `for` loop, nor any other control flow outside the closure, but it may
be a more legible style for tying up the end of a long iterator chain.
This was tried before in #14911, but nobody made the case for using it
with longer iterators. There was also `Iterator::advance` at that time
which was more capable than `for_each`, but that no longer exists.
The `itertools` crate has `Itertools::foreach` with the same behavior,
but thankfully the names won't collide. The `rayon` crate also has a
`ParallelIterator::for_each` where simple `for` loops aren't possible.
> I really wish we had `for_each` on seq iterators. Having to use a
> dummy operation is annoying. - [@nikomatsakis][1]
[1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
This works like a `for` loop in functional style, applying a closure to
every item in the `Iterator`. It doesn't allow `break`/`continue` like
a `for` loop, nor any other control flow outside the closure, but it may
be a more legible style for tying up the end of a long iterator chain.
This was tried before in #14911, but nobody made the case for using it
with longer iterators. There was also `Iterator::advance` at that time
which was more capable than `for_each`, but that no longer exists.
The `itertools` crate has `Itertools::foreach` with the same behavior,
but thankfully the names won't collide. The `rayon` crate also has a
`ParallelIterator::for_each` where simple `for` loops aren't possible.
> I really wish we had `for_each` on seq iterators. Having to use a
> dummy operation is annoying. - [@nikomatsakis][1]
[1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
add `FromStr` Impl for `char`
fixes#24939.
is it possible to use pub(restricted) instead of using a stability attribute for the internal error representation? is it needed at all?
Allocator integration
Lets start getting some feedback on `trait Alloc`.
Here is:
* the `trait Alloc` itself,
* the `struct Layout` and `enum AllocErr` that its API relies on
* a `struct HeapAlloc` that exposes the system allocator as an instance of `Alloc`
* an integration of `Alloc` with `RawVec`
* ~~an integration of `Alloc` with `Vec`~~
TODO
* [x] split `fn realloc_in_place` into `grow` and `shrink` variants
* [x] add `# Unsafety` and `# Errors` sections to documentation for all relevant methods
* [x] remove `Vec` integration with `Allocator`
* [x] add `allocate_zeroed` impl to `HeapAllocator`
* [x] remove typedefs e.g. `type Size = usize;`
* [x] impl `trait Error` for all error types in PR
* [x] make `Layout::from_size_align` public
* [x] clarify docs of `fn padding_needed_for`.
* [x] revise `Layout` constructors to ensure that [size+align combination is valid](https://github.com/rust-lang/rust/pull/42313#issuecomment-306845446)
* [x] resolve mismatch re requirements of align on dealloc. See [comment](https://github.com/rust-lang/rust/pull/42313#issuecomment-306202489).
Add `_` to the list of keywords
also, make sure the keyword table is correctly spaced
note: the reference also needs to be updated. This is not the only way to do this in the grammar, but it's my preferred way.
Autogenerate stubs and SUMMARY.md in the unstable book
Removes a speed bump in compiler development by autogenerating stubs for features in the unstable book. See #42454 for discussion.
The PR contains three commits, separated in order to make review easy:
* The first commit converts the tidy tool from a binary crate to a crate that contains both a library and a binary. In the second commit, we'll use the tidy library
* The second and main commit introduces autogeneration of SUMMARY.md and feature stub files
* The third commit turns off the tidy lint that checks for features without a stub, and removes the stub files. A separate commit due to the large number of files touched
Members of the doc team who wish to document some features can either do this (where `$rustsrc` is the root of the rust repo git checkout):
1. cd to `$rustsrc/src/tools/unstable-book-gen` and then do `cargo run $rustsrc/src $rustsrc/src/doc/unstable-book` to put the stubs into the unstable book
2. cd to `$rustsrc` and run `git ls-files --others --exclude-standard` to list the newly added stubs
3. choose a file to edit, then `git add` it and `git commit`
4. afterwards, remove all changes by the tool by doing `git --reset hard` and `git clean -f`
Or they can do this:
1. remove the comment marker in `src/tools/tidy/src/unstable_book.rs` line 122
2. run `./x.py test src/tools/tidy` to list the unstable features which only have stubs
3. revert the change in 1
3. document one of the chosen unstable features
The changes done by this PR also allow for further development:
* tidy obtains information about tracking issues. We can now forbid differing tracking issues between differing `#![unstable]` annotations. I haven't done this but plan to in a future PR
* we now have a general framework for generating stuff for the unstable book at build time. Further changes can autogenerate a list of the API a given library feature exposes.
The old way to simply click through the documentation after it has been uploaded to rust-lang.org works as well.
r? @nagisa
Fixes#42454
Remove struct_field_attributes feature gate
Part of #41681. ~This PR only removes the feature gate; this *does not* update any documentations.~ This PR removes the feature gate and the corresponding chapter of the Unstable Book.
I'm not very sure about the changes I made though... Just followed the stabilization guideline.
r? @nikomatsakis
