Shorten the `lookup_line` code slightly
The `match` looks like it's exactly the same as `checked_sub(1)`, so we might as well see if perf says we can just do that to save a couple lines.
Use ptr::metadata in <[T]>::len implementation
This avoids duplication of ptr::metadata code.
I believe this is acceptable as the previous approach essentially duplicated `ptr::metadata` because back then `rustc_allow_const_fn_unstable` annotation did not exist.
I would like somebody to ping `@rust-lang/wg-const-eval` as the documentation says:
> Always ping `@rust-lang/wg-const-eval` if you are adding more rustc_allow_const_fn_unstable attributes to any const fn.
Rollup of 11 pull requests
Successful merges:
- #100462 (Clarify `array::from_fn` documentation)
- #101644 (Document surprising and dangerous fs::Permissions behaviour on Unix)
- #103005 (kmc-solid: Handle errors returned by `SOLID_FS_ReadDir`)
- #103140 (Add diagnostic for calling a function with the same name with unresolved Macro)
- #103254 (rustdoc: do not filter out cross-crate `Self: Sized` bounds)
- #103347 (bootstrap: also create rustc-src component in sysroot)
- #103402 (Fix wrapped valid-range handling in ty_find_init_error)
- #103414 (Pretty print lifetimes captured by RPIT)
- #103424 (rustdoc: remove no-op CSS `.code-header { border-bottom: none }`)
- #103434 (Use functions for jump-to-def-background rustdoc GUI test)
- #103447 (`MaybeUninit`: use `assume_init_drop()` in the partially initialized array example)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
`MaybeUninit`: use `assume_init_drop()` in the partially initialized array example
The `assume_init_drop()` method does the same thing as the pointer conversion, and makes the example more straightforward.
rustdoc: remove no-op CSS `.code-header { border-bottom: none }`
The code headers are always h3 or h4, which don't have border-bottom by default anyway.
Pretty print lifetimes captured by RPIT
This specifically makes the output in #103409 change from:
```diff
error: `impl` item signature doesn't match `trait` item signature
--> $DIR/signature-mismatch.rs:15:5
|
LL | fn async_fn(&self, buff: &[u8]) -> impl Future<Output = Vec<u8>>;
| ----------------------------------------------------------------- expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
...
LL | fn async_fn<'a>(&self, buff: &'a [u8]) -> impl Future<Output = Vec<u8>> + 'a {
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
|
= note: expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
- found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
= help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait`
= help: verify the lifetime relationships in the `trait` and `impl` between the `self` argument, the other inputs and its output
error: aborting due to previous error
```
Along with the UI tests in this PR, which I think are all improvements!
r? `@oli-obk` though feel free to re-roll
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
`ty_find_init_error` assumed that `lo > 0` means the type cannot contain a
zero.
Fix it to handle wrapping ranges.
rustdoc: do not filter out cross-crate `Self: Sized` bounds
All type parameters **except `Self`** are implicitly `Sized` ([via](https://doc.rust-lang.org/nightly/std/marker/trait.Sized.html)). Previously, we disregarded the exception of `Self` and omitted cross-crate `Sized` bounds of *any* type parameter *including* `Self` when rendering.
From now on, we *do* render cross-crate `Self: Sized` bounds.
Most notably, in `std` we now finally properly render the `Sized` bound of the `Clone` trait as well as the `Self: Sized` bound on `Iterator::map`.
Fixes#24183.
``@rustbot`` label T-rustdoc A-cross-crate-reexports
r? rustdoc
kmc-solid: Handle errors returned by `SOLID_FS_ReadDir`
Fixes the issue where the `std::fs::ReadDir` implementaton of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets silently suppressed errors returned by the underlying `SOLID_FS_ReadDir` system function. The new implementation correctly handles all cases:
- `SOLID_ERR_NOTFOUND` indicates the end of directory stream.
- `SOLID_ERR_OK` + non-empty `d_name` indicates success.
- Some old filesystem drivers may return `SOLID_ERR_OK` + empty `d_name` to indicate the end of directory stream.
- Any other negative values (per ITRON convention) represent an error.
Document surprising and dangerous fs::Permissions behaviour on Unix
This documents the very surprising behaviour that `set_readonly(false)` will make a file *world writable* on Unix. I would go so far as to say that this function should be deprecated on Unix, or maybe even entirely. But documenting the bad behaviour is a good first step.
Fixes#74895
Clarify `array::from_fn` documentation
I've seen quite a few of people on social media confused of where the length of array is coming from in the newly stabilized `array::from_fn` example.
This PR tries to clarify the documentation on this.
Upgrade dist-mips*-linux to ubuntu:22.04 + crosstool-ng
These have no change in compatibility, still Linux 4.4 and glibc 2.23.
The main motivation for upgrading is that LLVM 16 will require at least GCC 7.1. Using crosstool-ng lets us choose our own toolchain versions, and then the Ubuntu version doesn't matter so much, just for the host compilation while we cross-compile.
Eliminate 280-byte memset from ReadDir iterator
This guy:
1536ab1b38/library/std/src/sys/unix/fs.rs (L589)
It turns out `libc::dirent64` is quite big—https://docs.rs/libc/0.2.135/libc/struct.dirent64.html. In #103135 this memset accounted for 0.9% of the runtime of iterating a big directory.
Almost none of the big zeroed value is ever used. We memcpy a tiny prefix (19 bytes) into it, and then read just 9 bytes (`d_ino` and `d_type`) back out. We can read exactly those 9 bytes we need directly from the original entry_ptr instead.
## History
This code got added in #93459 and tweaked in #94272 and #94750.
Prior to #93459, there was no memset but a full 280 bytes were being copied from the entry_ptr.
<table><tr><td>copy 280 bytes</td></tr></table>
This was not legal because not all of those bytes might be initialized, or even allocated, depending on the length of the directory entry's name, leading to a segfault. That PR fixed the segfault by creating a new zeroed dirent64 and copying just the guaranteed initialized prefix into it.
<table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td></tr></table>
However this was still buggy because it used `addr_of!((*entry_ptr).d_name)`, which is considered UB by Miri in the case that the full extent of entry_ptr is not in bounds of the same allocation. (Arguably this shouldn't be a requirement, but here we are.)
The UB got fixed by #94272 by replacing `addr_of` with some pointer manipulation based on `offset_from`, but still fundamentally the same operation.
<table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td></tr></table>
Then #94750 noticed that only 9 of those 19 bytes were even being used, so we could pick out only those 9 to put in the ReadDir value.
<table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td><td>copy 9 bytes</td></tr></table>
After my PR we just grab the 9 needed bytes directly from entry_ptr.
<table><tr><td>copy 9 bytes</td></tr></table>
The resulting code is more complex but I believe still worthwhile to land for the following reason. This is an extremely straightforward thing to accomplish in C and clearly libc assumes that; literally just `entry_ptr->d_name`. The extra work in comparison to accomplish it in Rust is not an example of any actual safety being provided by Rust. I believe it's useful to have uncovered that and think about what could be done in the standard library or language to support this obvious operation better.
## References
- https://man7.org/linux/man-pages/man3/readdir.3.html
This allows porting uses of span_suggestions() to diagnostic structs.
Doesn't work for multipart_suggestions() because the rank would be
reversed - the struct would specify multiple spans, each of which has
multiple possible replacements, while multipart_suggestions() creates
multiple possible replacements, each with multiple spans.
Enable LTO for rustc_driver.so
Alternative to https://github.com/rust-lang/rust/pull/97154
This enables LTO'ing dylibs behind a feature flag and uses this feature for compiling rustc_driver.so.
