Upstream has removed the shootout-regex-dna example.

…VM sysroot

cc #1395

…ub job summary

add test for a function ABI mismatch due to target features

Cc rust-lang/miri#3095

…y_ref_mut`

Move `needless_pass_by_ref_mut`: `suspicious` -> `nursery`

[Related to [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/needless_pass_by_ref_mut.20isn't.20ready.20for.20stable)]

`needless_pass_by_ref_mut` has been released with some important bugs (notably having a lot of reported false positives and an ICE). So it may not be really ready for being in stable until these problems are solved. This PR changes the lint's category from `suspicious` to `nursery`, just that.
changelog: none

std_instead_of_core: avoid lint inside of proc-macro

- fixes rust-lang/rust-clippy#10198

note: The lint for the reported `thiserror::Error` has been suppressed by [Don't lint unstable moves in std_instead_of_core](https://github.com/rust-lang/rust-clippy/pull/9545/files#diff-2cb8a24429cf9d9898de901450d640115503a10454d692dddc6a073a299fbb7eR29) because `thiserror::Error`  internally implements `std::error::Error for (derived struct)`.

changelog: [`std_intead_of_core`]: avoid linting inside proc-macro

I confirmed this change fixes the problem:
<details>
<summary>test result without the change</summary>

```console
error: used import from `std` instead of `core`
  --> tests/ui/std_instead_of_core.rs:65:14
   |
LL |     #[derive(ImplStructWithStdDisplay)]
   |              ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the derive macro `ImplStructWithStdDisplay` (in Nightly builds, run with -Z macro-backtrace for more info)
```
</details>

Based on #99883 by @Arc-blroth
Depends on rust-lang/backtrace-rs#556 and rust-lang/cc-rs#705

Make subtyping explicit in MIR

This adds new mir-opt that pushes new `ProjectionElem` called `ProjectionElem::Subtype(T)` to `Rvalue` of a subtyped assignment so we can unsoundness issues like rust-lang/rust#107205

Addresses rust-lang/rust#112651

r? `@lcnr`

Make subtyping explicit in MIR

This adds new mir-opt that pushes new `ProjectionElem` called `ProjectionElem::Subtype(T)` to `Rvalue` of a subtyped assignment so we can unsoundness issues like rust-lang/rust#107205

Addresses rust-lang/rust#112651

r? `@lcnr`

Avoid invoking `ignored_unit_patterns` in macro definition

Fixes rust-lang/rust-clippy#11601

The reported problem occured in [a derive macro](https://github.com/mpalmer/ct-structs/actions/runs/6386980382/job/17334587328#step:6:239). This PR avoid linting in macros.

changelog: [`ignored_unit_patterns`] No longer lints inside macro definitions

Fix: avoid changing drop order

Fixes rust-lang/rust-clippy#11599

changelog: [`redundant_locals`] No longer lints which implements Drop trait to avoid reordering

Fix typos `*ucom` → `ucom*`

```
error: expected one of `,`, `:`, or `}`, found `.`
  --> $DIR/missing-fat-arrow.rs:25:14
   |
LL |         Some(a) if a.value == b {
   |                               - while parsing this struct
LL |             a.value = 1;
   |             -^ expected one of `,`, `:`, or `}`
   |             |
   |             while parsing this struct field
   |
help: try naming a field
   |
LL |             a: a.value = 1;
   |               
help: you might have meant to start a match arm after the match guard
   |
LL |         Some(a) if a.value == b => {
   |                                   
```

Fix #78585.

[rustdoc] Show enum discrimant if it is a C-like variant

Fixes rust-lang/rust#101337.

We currently display values for associated constant items in traits:

![image](https://github.com/rust-lang/rust/assets/3050060/03e566ec-c670-47b4-8ca2-b982baa7a0f4)

And we also display constant values like [here](file:///home/imperio/rust/rust/build/x86_64-unknown-linux-gnu/doc/std/f32/consts/constant.E.html).

I think that for coherency, we should display values of C-like enum variants.

With this change, it looks like this:

![image](https://github.com/rust-lang/rust/assets/3050060/b53fbbe0-bdb1-4289-8537-f2dd4988e9ac)

As for the display of the constant value itself, I used what we already have to keep coherency.

We display the C-like variants value in the following scenario:
 1. It is a C-like variant with a value set => all the time
 2. It is a C-like variant without a value set: All other variants are C-like variants and at least one them has its value set.

Here is the result in code:

```rust
// Ax and Bx value will be displayed.
enum A {
    Ax = 12,
    Bx,
}

// Ax and Bx value will not be displayed
enum B {
    Ax,
    Bx,
}

// Bx value will not be displayed
enum C {
    Ax(u32),
    Bx,
}

// Bx value will not be displayed, Cx value will be displayed.
#[repr(u32)]
enum D {
    Ax(u32),
    Bx,
    Cx = 12,
}
```

r? `@notriddle`

improve the suggestion of `generic_bound_failure`

- Fixes #115375
- suggest the bound in the correct scope: trait or impl header vs assoc item. See `tests/ui/suggestions/lifetimes/type-param-bound-scope.rs`
- don't suggest a lifetime name that conflicts with the other late-bound regions of the function:
```rust
type Inv<'a> = *mut &'a ();
fn check_bound<'a, T: 'a>(_: T, _: Inv<'a>) {}
fn test<'a, T>(_: &'a str, t: T, lt: Inv<'_>) { // suggests a new name `'a`
    check_bound(t, lt); //~ ERROR
}
```

…rrors

Fix suggestion span involving wrongly placed generic arg on variant

Fixes #116473

The span computation was wrong. It went from the end of the variant to the end of the (wrongly placed) args. However, the variant lived in a different expansion and this resulted in a nonsensical span that overlaps with another and thereby leads to the ICE.

In the fix I've changed span computation to not be based on the location of the variant, but purely on the location of the args. I simply extend the start of the args span 2 positions to the left and that includes the `::` and that's all we need apparently.

This approach produces a correct span regardless of which macro/expansion the args reside in and where the variant is.

In smir `find_crates` returns `Vec<Crate>` instead of `Option<Crate>`

Addresses rust-lang/project-stable-mir#40

r? `@oli-obk`

Simplify some mir passes by using let chains

Sync rustc_codegen_cranelift

The highlights this time are improved simd and inline asm support, `is_x86_feature_detected!()` returning the actual cpu features when inline asm support is enabled and a couple of bug fixes.

r? ```@ghost```

```@rustbot``` label  A-codegen  A-cranelift  T-compiler  subtree-sync

Add a test for fixed ICE

Addresses rust-lang/rust#115517 (comment)

Closes #115517

r? ``@compiler-errors``

Rollup of 6 pull requests

Successful merges:

 - #115882 (improve the suggestion of `generic_bound_failure`)
 - #116537 (Fix suggestion span involving wrongly placed generic arg on variant)
 - #116543 (In smir `find_crates` returns `Vec<Crate>` instead of `Option<Crate>`)
 - #116549 (Simplify some mir passes by using let chains)
 - #116556 (Sync rustc_codegen_cranelift)
 - #116561 (Add a test for fixed ICE)

r? `@ghost`
`@rustbot` modify labels: rollup

…strap, r=albertlarsan68

Add RUSTFLAGS_BOOTSTRAP to RUSTFLAGS for bootstrap compilation

Adds `RUSTFLAGS_BOOTSTRAP` to `RUSTFLAGS` for bootstrap compilation when `RUSTFLAGS_BOOTSTRAP` exists in the environment. With this PR, `RUSTFLAGS_BOOTSTRAP` will affect every build(as we already do for rustc and std) compiled with stage0 compiler.

Resolves #94234

Extend `impl`'s `def_span` to include its where clauses

Typically, we highlight the def-span of an impl in a diagnostic due to either:
1. coherence error
2. trait evaluation cycle
3. invalid implementation of built-in trait

I find that an impl's where clauses are very often required to understanding why these errors come about, which is unfortunate since where clauses may be located on different lines and don't show up in the error. This PR expands the def-span of impls to include these where clauses.

r? cjgillot since you've touched this code a while back to make some spans shorter, but you can also reassign to wg-diagnostics or compiler if you're busy or have no strong opinions.

Support AIX in Rust standard library

Also containing original contributions from `@bzEq` .

This commit is generated by `ferrocene/tools/pull-upstream/pull.sh`.
The list of excluded files is defined in `.gitattributes`.