Implement indexing slices with pairs of core::ops::Bound<usize>
Closes#49976.
I am not sure about code duplication between `check_range` and `into_maybe_range`. Should be former implemented in terms of the latter? Also this PR doesn't address code duplication between `impl SliceIndex for Range*`.
Add missing information on what standard-library features are supported
by the UEFI targets.
All current UEFI targets (which is i686 and x86_64) only support no_std
cross-compilations. `std` support has not been worked on and is unlikely
to emerge anytime soon, due to the much restricted environment that UEFI
provides.
Switch transmute_ptr_to_ptr to "pedantic" class.
Per discussion in https://github.com/rust-lang/rust-clippy/issues/6372, this lint has significant false positives.
changelog: transmute_ptr_to_ptr defaults to "allow".
bootstrap: Restore missing --bulk-dirs for rust-docs, rustc-docs
The `--bulk-dirs` argument was removed for rust-docs in commit c768ce1384 and rustc-docs in commit 8ca46fc7a8 (#79788), presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown.
Fixes#80684.
Cc `@pietroalbini.`
With the arrival of min const generics, many alt-vec libraries have
updated to use it in some way and arrayvec is no exception. Use the
latest with minor refactoring.
Also, rustc_workspace_hack is the only user of smallvec 0.6 in the
entire tree, so drop it.
Rollup of 12 pull requests
Successful merges:
- #84013 (Replace all `fmt.pad` with `debug_struct`)
- #84119 (Move `sys::vxworks` code to `sys::unix`)
- #84212 (Replace `Void` in `sys` with never type)
- #84251 (fix 'const-stable since' for NonZeroU*::new_unchecked)
- #84301 (Document that `index` and `index_mut` can panic)
- #84365 (Improve the docstrings of the `Lto` struct.)
- #84378 (Fix broken doc link)
- #84379 (Add GAT related tests)
- #84380 (Write Rustdoc titles like "x in crate::mod - Rust")
- #84390 (Format `Struct { .. }` on one line even with `{:#?}`.)
- #84393 (Support `x.py doc std --open`)
- #84406 (Remove `delete` alias from `mem::drop`.)
Failed merges:
- #84387 (Move `sys_common::poison` to `sync::poison`)
r? `@ghost`
`@rustbot` modify labels: rollup
bump jobserver dependency
the newest jobserver version should slightly reduce context switches
in highly parallel build environments on linux kernels >= 5.6
Support `x.py doc std --open`
I usually run this command:
```
./x.py doc std --stage 1 --jobs 8
```
Then I gave a try to `--open` and realized it wasn't working. I finally realized it was simply because it was only handling paths starting with `library`. This PR allows to handle both kinds of paths.
cc ``@jyn514``
r? ``@Mark-Simulacrum``
Format `Struct { .. }` on one line even with `{:#?}`.
The result of `debug_struct("A").finish_non_exhaustive()` before this change:
```
A {
..
}
```
And after this change:
```
A { .. }
```
If there's any fields, the result stays unchanged:
```
A {
field: value,
..
}
Write Rustdoc titles like "x in crate::mod - Rust"
This makes Rustdoc titles for items be like "Widget in cratename::blah::foo - Rust". Titles for modules and other non-items are unchanged, and still read like "cratename::blah::foo - Rust". This makes managing several open Rustdoc tabs easier.
This also adds some tests for the new title behavior.
Closes#84371.
fix 'const-stable since' for NonZeroU*::new_unchecked
For the unsigned `NonZero` types, `new_unchecked` was const-stable from the start with https://github.com/rust-lang/rust/pull/50808. Fix the docs to accurately reflect that.
I think this `since` is also incorrect:
```rust
#[stable(feature = "from_nonzero", since = "1.31.0")]
impl From<$Ty> for $Int {
```
The signed nonzero types were only stabilized in 1.34, so that `From` impl certainly didn't exist before. But I had enough of digging through git histories after I figured out when `new_unchecked` became const-stable...^^
Replace `Void` in `sys` with never type
This PR replaces several occurrences in `sys` of the type `enum Void {}` with the Rust never type (`!`).
The name `Void` is unfortunate because in other languages (C etc.) it refers to a unit type, not an uninhabited type.
Note that the previous stabilization of the never type was reverted, however all uses here are implementation details and not publicly visible.
Move `sys::vxworks` code to `sys::unix`
Follow-up to #77666, `sys::vxworks` is almost identical to `sys::unix`, the only differences are the `rand`, `thread_local_dtor`, and `process` implementation. Since `vxworks` is `target_family = unix` anyway, there is no reason for the code not to live inside of `sys::unix` like all the other unix-OSes.
e41f378f82/compiler/rustc_target/src/spec/vxworks_base.rs (L12)
``@rustbot`` label: +T-libs-impl
Replace all `fmt.pad` with `debug_struct`
This replaces any occurrence of:
- `f.pad("X")` with `f.debug_struct("X").finish()`
- `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()`
This is in line with existing formatting code such as
1255053067/library/std/src/sync/mpsc/mod.rs (L1470-L1475)
Upgrade `expat` dependency in riscv64 to newer version.
The old version was renamed to `expat-2.2.6-RENAMED-VULNERABLE-PLEASE-USE-2.3.0-INSTEAD`. :)
r? `@Mark-Simulacrum`
This commit updates rustc, with an applicable LLVM version, to use
LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating
floating-point-to-int conversions. This results in a little bit tighter
codegen for x86/x86_64, but the main purpose of this is to prepare for
upcoming changes to the WebAssembly backend in LLVM where wasm's
saturating float-to-int instructions will now be implemented with these
intrinsics.
This change allows simplifying a good deal of surrounding code, namely
removing a lot of wasm-specific behavior. WebAssembly no longer has any
special-casing of saturating arithmetic instructions and the need for
`fptoint_may_trap` is gone and all handling code for that is now
removed. This means that the only wasm-specific logic is in the
`fpto{s,u}i` instructions which only get used for "out of bounds is
undefined behavior". This does mean that for the WebAssembly target
specifically the Rust compiler will no longer be 100% compatible with
pre-LLVM 12 versions, but it seems like that's unlikely to be relied on
by too many folks.
Note that this change does immediately regress the codegen of saturating
float-to-int casts on WebAssembly due to the specialization of the LLVM
intrinsic not being present in our LLVM fork just yet. I'll be following
up with an LLVM update to pull in those patches, but affects a few other
SIMD things in flight for WebAssembly so I wanted to separate this change.
Eventually the entire `cast_float_to_int` function can be removed when
LLVM 12 is the minimum version, but that will require sinking the
complexity of it into other backends such as Cranelfit.
