…bol names

…ince it was used as an example when discussing possible problems

fixes rust-lang#124669

People keep making fun of this signature for being so gnarly.
Associated type bounds lend it a much simpler scribbling.
ChangeOutputType can also come along for the ride.

Instead of not generating the function at all on big endian (which
makes the CHECK lines fail), instead use to_le() on big endian,
so that we essentially perform a bswap for both endiannesses.

Currently it can be made to fail by rearranging code within
`compiler/rustc_mir_transform/src/lint.rs`.

PR rust-lang#125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.

So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of rust-lang#125443 and
updates the patch file accordingly.

The motivation is that rust-lang#125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.

…g QuesionMark `?` in the body.

We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
  `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
  sometimes the order is alphabetical, and sometimes there is no
  particular order.
- Sometimes the attributes of a particular kind aren't even grouped
  all together, e.g. there might be a `feature`, then an `allow`, then
  another `feature`.

This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
  because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
  ignored in `rustfmt.toml`).

…=scottmcm

DOC: Add FFI example for slice::from_raw_parts()

For some discussion, see https://users.rust-lang.org/t/missing-guidance-on-converting-ffi-ptr-length-to-slice/106048

See also rust-lang#120608.

…r-demangling-recommendation, r=davidtwco

Recommend to never display zero disambiguators when demangling v0 symbols

This PR extends the [v0 symbol mangling documentation](https://doc.rust-lang.org/rustc/symbol-mangling/v0.html) with the strong recommendation that demanglers should never display zero-disambiguators, especially when dealing with `crate-root`.

Being able to rely on `C3foo` to be rendered as `foo` (i.e. without explicit disambiguator value) rather than as `foo[0]` allows the compiler to encode things like new basic types in a backward compatible way. This idea has been originally proposed by `@eddyb` in [the discussion around supporting `f16` and `f128` in the v0 mangling scheme](rust-lang#122106). It is a generally useful mechanism for supporting a certain class of new elements in the v0 mangling scheme in a backward compatible way (whether as a temporary workaround until downstream tooling has picked up grammar changes or as a permanent encoding).

cc `@tgross35`

…solidate-assoc-item-access-checking, r=davidtwco

Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking

Use `probe_assoc_item` (for hygienically probing an assoc item and checking if it's accessible wrt. visibility and stability) for assoc item constraints, too, not just for assoc type paths and make the privacy error translatable.

…ssmode, r=davidtwco

Nvptx remove direct passmode

This PR does what should have been done in rust-lang#117671. That is fully avoid using the `PassMode::Direct` for `extern "C" fn` for `nvptx64-nvidia-cuda` and enable the compatibility test. `@RalfJung` [pointed me in the right direction](rust-lang#117480 (comment)) for solving this issue.

There are still some ABI bugs after this PR is merged. These ABI tests are created based on what is actually correct, and since they continue passing with even more of them enabled things are improving. I don't have the time to tackle all the remaining issues right now, but I think getting these improvements merged is very valuable in themselves and plan to tackle more of them long term.

This also doesn't remove the use of `PassMode::Direct` for `extern "ptx-kernel" fn`. This was also not trivial to make work. And since the ABI is hidden behind an unstable feature it's less urgent.

I don't know if it's correct to request `@RalfJung` as a reviewer (due to team structures), but he helped me a lot to figure out this stuff. If that's not appropriate then `@davidtwco` would be a good candidate since he know about this topic from rust-lang#117671

r​? `@RalfJung`

For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.

Adding suggestions for following function in E0277.

```rust
fn main() {
    let mut _file = File::create("foo.txt")?;
}
```

to

```rust
fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut _file = File::create("foo.txt")?;

    return Ok(());
}
```

According to the issue rust-lang#125997, only the code examples in the issue are targeted, but the issue covers a wider range of situations.

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

…=workingjubilee

docs(core): make more const_ptr doctests assert instead of printing

improves on rust-lang#124669

…gnature, r=scottmcm

Simplify `[T; N]::try_map` signature

People keep making fun of this signature for being so gnarly.
Associated type bounds admit a much simpler scribbling.

r? ````@scottmcm````

…tlarsan68

Add {{target}} substitution to compiletest

In ferrocene we have ui tests testing the cli interface of the compiler, one of which tests the `--target` flag. To be able to run this on all targets we require a way to specify a valid target in the `compile-flags` directive that is target independent, as otherwise we can only run the test against the one target we choose to supply in the flags. See https://github.com/ferrocene/ferrocene/blob/383cbc80f4e85859a4055f121f15dac329908346/tests/ui/ferrocene/compiler-arguments/target/target.rs

We figured the project might be able to make use of this substitution as well in the future.

try-job: dist-x86_64-msvc

…eyouxu

Make issue-122805.rs big endian compatible

Instead of not generating the function at all on big endian (which makes the CHECK lines fail), instead use to_le() on big endian, so that we essentially perform a bswap for both endiannesses.

set_env: State the conclusion upfront

People tend to skim or skip over long explanations so we should be very upfront that `set_var` and `remove_var` are being made unsafe for a very good reason.

This is just the conclusion restated almost verbatim but earlier in the docs and separated from the explanation:

https://github.com/rust-lang/rust/blob/0c960618b56f662d933e8b864cd9632a99174e87/library/std/src/env.rs#L338-L339

I think this may help with people who may not be entirely comfortable with rust-lang#125937 being rejected.

Make `storage-live.rs` robust against rustc internal changes.

Currently it can be made to fail by rearranging code within `compiler/rustc_mir_transform/src/lint.rs`.

This is a precursor to rust-lang#125443.

r? ```@lqd```

…ch, r=bjorn3

Update a cranelift patch file for formatting changes.

PR rust-lang#125443 will reformat all the use declarations in the repo. This would break a patch kept in `rustc_codegen_cranelift` that gets applied to `library/std/src/sys/pal/windows/rand.rs`.

So this commit formats the use declarations in `library/std/src/sys/pal/windows/rand.rs` in advance of rust-lang#125443 and updates the patch file accordingly.

The motivation is that rust-lang#125443 is a huge change and we want to get fiddly little changes like this out of the way so it can be nothing more than an `x fmt --all`.

r? ``@bjorn3``

… r=davidtwco

Use `tidy` to sort crate attributes for all compiler crates.

We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order.
- Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`.

This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`).

r? `@davidtwco`

…ring-utf8-invariant, r=joboet

Make PathBuf less Ok with adding UTF-16 then `into_string`

Fixes rust-lang#126291 which is, as far as I can tell, a regression introduced by rust-lang#96869.

try-job: x86_64-msvc

…efer-rlib, r=Kobzol

Migrate run make prefer rlib

Part of rust-lang#121876.

r? `@jieyouxu`

fix RELEASES: we do not support upcasting to auto traits

rust-lang#119338 does not actually support casts from `dyn Trait` to `dyn Auto`, only from `dyn Trait` to `dyn Trait + Auto`. The following test does not compile

```rust
trait Trait: Send {}
impl<T: Send> Trait for T {}

fn foo() {
    let x: &i32 = &1;
    let y = x as &dyn Trait as &dyn Send;
}
```
it actually also doesn't compile with `feature(trait_upcasting)`, opened rust-lang#126313 for that

r? `@Mark-Simulacrum` `@cuviper`