This PR makes a number of changes to the UNIX randomness implementation:
* Use `io::Error` for centralized error handling
* Move the file-fallback logic out of the `getrandom`-specific module
* Stop redefining the syscalls on macOS and DragonFly, they have appeared in `libc`
* Add a `OnceLock` to cache the random device file descriptor

…gers.

Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a
single DISubprogram. That, however, triggered assertions because parameters
weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a
DILexicalScope below the DISubprogram and parent all of the parameters to that
scope. That fixed the assertion, but debuggers (including gdb and lldb) don't
recognize variables that are not parented to the subprogram itself as parameters,
even if they are emitted with DW_TAG_formal_parameter.

Consider the program:

use std::env;

fn square(n: i32) -> i32 {
    n * n
}

fn square_no_inline(n: i32) -> i32 {
    n * n
}

fn main() {
    let x = square(env::vars().count() as i32);
    let y = square_no_inline(env::vars().count() as i32);
    println!("{x} == {y}");
}

When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07)

(gdb) r
Starting program: /ephemeral/tmp/target/release/tmp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, tmp::square () at src/main.rs:5
5	    n * n
(gdb) info args
No arguments.
(gdb) info locals
n = 31
(gdb) c
Continuing.

Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10
10	    n * n
(gdb) info args
n = 31
(gdb) info locals
No locals.

This issue is particularly annoying because it removes arguments from stack traces.

The DWARF for the inlined function looks like this:

< 2><0x00002132 GOFF=0x00002132>      DW_TAG_subprogram
                                        DW_AT_linkage_name          _ZN3tmp6square17hc507052ff3d2a488E
                                        DW_AT_name                  square
                                        DW_AT_decl_file             0x0000000f /ephemeral/tmp/src/main.rs
                                        DW_AT_decl_line             0x00000004
                                        DW_AT_type                  0x00001a56<.debug_info+0x00001a56>
                                        DW_AT_inline                DW_INL_inlined
< 3><0x00002142 GOFF=0x00002142>        DW_TAG_lexical_block
< 4><0x00002143 GOFF=0x00002143>          DW_TAG_formal_parameter
                                            DW_AT_name                  n
                                            DW_AT_decl_file             0x0000000f /ephemeral/tmp/src/main.rs
                                            DW_AT_decl_line             0x00000004
                                            DW_AT_type                  0x00001a56<.debug_info+0x00001a56>
< 4><0x0000214e GOFF=0x0000214e>          DW_TAG_null
< 3><0x0000214f GOFF=0x0000214f>        DW_TAG_null

That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing
'n' as a parameter.

This patch removes the additional lexical scope. Parameters can be easily
deduplicated by a tuple of their scope and the argument index, at the trivial
cost of taking a Hash + Eq bound on DIScope.

Co-authored-by: Georg Semmler <github@weiznich.de>

also make it fail if there's a compression issue

zlib is seemingly always enabled, so we can test it unconditionally

it now checks zlib and zstd, via rustc and rust-lld

move it where it's used, and name it like the other scripts

…Denton

std: refactor UNIX random data generation

This PR makes a number of changes to the UNIX randomness implementation:
* Use `io::Error` for centralized error handling
* Move the file-fallback logic out of the `getrandom`-specific module
* Stop redefining the syscalls on macOS and DragonFly, they have appeared in `libc`
* Add a `OnceLock` to cache the random device file descriptor

…, r=lcnr

Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver

Realized that the new solver didn't handle ptr-to-ptr casting correctly.

r? lcnr

Built on rust-lang#128694

…ginfo, r=wesleywiser

Rework MIR inlining debuginfo so function parameters show up in debuggers.

Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter.

Consider the program:

```rust
use std::env;

#[inline(always)]
fn square(n: i32) -> i32 {
    n * n
}

#[inline(never)]
fn square_no_inline(n: i32) -> i32 {
    n * n
}

fn main() {
    let x = square(env::vars().count() as i32);
    let y = square_no_inline(env::vars().count() as i32);
    println!("{x} == {y}");
}
```

When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07)

```
(gdb) r
Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, tmp::square () at src/main.rs:5
5	    n * n
(gdb) info args
No arguments.
(gdb) info locals
n = 31
(gdb) c
Continuing.

Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10
10	    n * n
(gdb) info args
n = 31
(gdb) info locals
No locals.
```

This issue is particularly annoying because it removes arguments from stack traces.

The DWARF for the inlined function looks like this:

```
< 2><0x00002132 GOFF=0x00002132>      DW_TAG_subprogram
                                        DW_AT_linkage_name          _ZN3tmp6square17hc507052ff3d2a488E
                                        DW_AT_name                  square
                                        DW_AT_decl_file             0x0000000f /ephemeral/tmp/src/main.rs
                                        DW_AT_decl_line             0x00000004
                                        DW_AT_type                  0x00001a56<.debug_info+0x00001a56>
                                        DW_AT_inline                DW_INL_inlined
< 3><0x00002142 GOFF=0x00002142>        DW_TAG_lexical_block
< 4><0x00002143 GOFF=0x00002143>          DW_TAG_formal_parameter
                                            DW_AT_name                  n
                                            DW_AT_decl_file             0x0000000f /ephemeral/tmp/src/main.rs
                                            DW_AT_decl_line             0x00000004
                                            DW_AT_type                  0x00001a56<.debug_info+0x00001a56>
< 4><0x0000214e GOFF=0x0000214e>          DW_TAG_null
< 3><0x0000214f GOFF=0x0000214f>        DW_TAG_null
```

That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter.

This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…k-Simulacrum

Add windows-targets crate to std's sysroot

With this PR, when backtrace is used as a crate from crates.io it will (once updated) use the real [windows-targets](https://crates.io/crates/windows-targets) crate. But when used from std it'll use std's replacement version.

This allows sharing our customized `windows_tagets::link!` macro between std proper and the backtrace crate when used as part of std, ensuring a consistent linking story. This will be especially important once we move to using [`raw-dylib`](https://doc.rust-lang.org/reference/items/external-blocks.html#dylib-versus-raw-dylib) by default.

…mpl, r=lcnr

Store `do_not_recommend`-ness in impl header

Alternative to rust-lang#128674

It's less flexible, but also less invasive. Hopefully it's also performant. I'd recommend we think separately about the design for how to gate arbitrary diagnostic attributes moving forward.

More work on `zstd` compression

r? `@Kobzol` as we've discussed this.

This is a draft to show the current approach of supporting zstd in compiletest, and making the tests using it unconditional.

Knowing whether llvm/lld was built with `LLVM_ENABLE_ZSTD` is quite hard, so there are two strategies. There are details in the code, and we can discuss this approach. Until we know the config used to build CI artifacts, it seems our options are somewhat limited in any case.

zlib compression seems always enabled, so we only check this in its dedicated test, allowing the test to ignore errors due to zstd not being supported.

The zstd test is made unconditional in what it tests, by relying on `needs-llvm-zstd` to be ignored when `llvm.libzstd` isn't enabled in `config.toml`.

try-job: x86_64-gnu

…nur-ozkan

bootstrap: clear miri ui-test deps when miri sysroot gets rebuilt

Second attempt after rust-lang#128683: seems like it's not the compiler changing that we care about, but the sysroot changing.

I did some local testing with sysroot rebuilds and it works fine for at least those cases I checked.

r? `@onur-ozkan`