libc::prctl and the prctl definitions in glibc, musl, and the kernel
headers are C variadic functions. Therefore, all the arguments (except
for the first) are untyped. It is only the Linux man page which says
that prctl takes 4 unsigned long arguments. I have no idea why it says
this.

In any case, the upshot is that we don't need to cast the pointer to an
integer and confuse Miri.

The current terse output gives 112 chars per line, which causes
wraparound for people using 100 char wide terminals, which is very
common.

This commit changes it to be exactly 100 wide, which makes the output
look much nicer.

This reverts commit 6d0b61e.

…rk-Simulacrum

Stabilize Stdin::lines.

Closes rust-lang#87096

Fcp completed here: rust-lang#87096 (comment)

…uviper

Don't cast thread name to an integer for prctl

`libc::prctl` and the `prctl` definitions in glibc, musl, and the kernel headers are C variadic functions. Therefore, all the arguments (except for the first) are untyped. It is only the Linux man page which says that `prctl` takes 4 `unsigned long` arguments. I have no idea why it says this.

In any case, the upshot is that we don't need to cast the pointer to an integer and confuse Miri.

But in light of this... what are we doing with those three `0`s? We're passing 3 `i32`s to `prctl`, which doesn't fill me with confidence. The man page says `unsigned long` and all the constants in the linux kernel are macros for expressions of the form `1UL << N`. I'm mostly commenting on this because looks a whole lot like some UB that was found in SQLite a few years ago: <https://youtu.be/LbzbHWdLAI0?t=1925> that was related to accidentally passing a 32-bit value from a literal `0` instead of a pointer-sized value. This happens to work on x86 due to the size of pointers and happens to work on x86_64 due to the calling convention. But also, there is no good reason for an implementation to be looking at those arguments. Some other calls to `prctl` require that other arguments be zeroed, but not `PR_SET_NAME`... so why are we even passing them?

I would prefer to end such questions by either passing 3 `libc::c_ulong`, or not passing those at all, but I'm not sure which is better.

…ut, r=Dylan-DPC

Improve terse test output.

The current terse output gives 112 chars per line, which causes
wraparound for people using 100 char wide terminals, which is very
common.

This commit changes it to be exactly 100 wide, which makes the output
look much nicer.

…r, r=compiler-errors

Revert "Mark Location::caller() as #[inline]"

This reverts rust-lang#95619. As noted in rust-lang#95619 (comment) this seems to break several tests with cg_clif.

…span, r=jsha

Switch item-info from div to span

Following discussion in rust-lang#95684.

cc `@jsha`
r? `@notriddle`