This updates the rust-version file to 029c9e1.

Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: rust-lang/rust@029c9e1
Filtered ref: rust-lang/rust-analyzer@912b3ed
Upstream diff: rust-lang/rust@43a4909...029c9e1

This merge was created using https://github.com/rust-lang/josh-sync.

Adopt uv's AI policy

Rustc pull update

…d-for-pattern, r=Mark-Simulacrum

perf: use `get_unchecked` for `TwoWaySearcher`



## What is this PR?

*This is related to rust-lang/rust#27721.*

This PR is a proposal for a performance improvement in `std::pattern`.  

Profiling of [https://github.com/quickwit-oss/quickwit](https://github.com/quickwit-oss/quickwit) in production shows that `TwoWaySearcher::next` is one of the most CPU-time-consuming functions, so I thought I would give it a look.  
I read the [contribution guide](https://std-dev-guide.rust-lang.org/development/perf-benchmarking.html) and this seems to be a fitting proposal.

It seems like `TwoWaySearcher::next` and `TwoWaySearcher::next_back` could be made faster by using `get_unchecked` in the inner loop comparisons instead of regular indexing, which is safe in the conditions where it would be done (indices are within bounds by construction).  
I added some `SAFETY` comments in the code to explain why this is safe, as I believe is customary in those cases (and according to [this page as well](https://std-dev-guide.rust-lang.org/policy/safety-comments.html)).

### Benchmarks

I ran the existing bencharmks before/after the changes (only on my laptop, I can run them in other places if that's necessary). 

```
./x.py bench library/coretests -- pattern::
```

We seem to be getting a ~7.5-12% performance improvement at a very low cost, which sounds worthwhile to me.  
But this is the first time I'm proposing a change in Rust, so I'm looking forward to feedback on this.

```
BEFORE CHANGES
    pattern::ends_with_char   3398.91ns/iter +/- 526.28
    pattern::ends_with_str    3545.04ns/iter +/- 1108.76
    pattern::starts_with_char 3348.31ns/iter +/- 352.38
    pattern::starts_with_str  3710.59ns/iter +/- 435.57

AFTER CHANGES
    pattern::ends_with_char   3125.99ns/iter +/- 567.09  (-8.03%)
    pattern::ends_with_str    3106.43ns/iter +/- 258.33  (-12.38%)
    pattern::starts_with_char 3094.55ns/iter +/- 595.42  (-7.59%)
    pattern::starts_with_str  3365.75ns/iter +/- 268.88  (-9.29%)
```

System info for the benchmarks run

<details>

```
Based on commit 8317fef

rustc 1.96.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: aarch64-apple-darwin
release: 1.96.0-dev
LLVM version: 22.1.2

Apple M4 Max
16
64 GB
ProductName:		macOS
ProductVersion:		26.3
BuildVersion:		25D125
(this was run on AC and without any heavy load from other apps or whatnot)
```

</details>

`rust-analyzer` subtree update

Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@57116fa.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost

Use alternate means of detecting enums in `is_udt`

This fixes a small regression from rust-lang/rust#155336

Flat enums are excluded from `is_udt` since LLDB natively handles them correctly. The previous logic (`SBType.IsScopedEnumerationType()`) behaved correctly for non-msvc targets, but for some reason on msvc enums don't count as scoped enumerations?

The new logic checks the type returned by `SBType.GetEnumerationIntegerType()`. If the queried type isn't an enum, the returned type is invalid. This behaves correctly on both msvc and non-msvc targets, and its behavior doesn't conflict with sum-type enums.

As always, testing on msvc isn't really possible atm. That should change soon though =)

---

try-job: aarch64-apple

…henkov

Staticlib hide internal symbols

According to issue rust-lang/rust#104707, when building a staticlib, all Rust internal symbols — mangled symbols, `#[rustc_std_internal_symbol]` items, allocator shims, etc. — leak out of the static archive. In contrast, cdylib correctly exports only `#[no_mangle]` symbols via a linker version script.

`-Zstaticlib-hide-internal-symbols` directly post-processes ELF object files in the archive: parsing the `SHT_SYMTAB` sections and setting `STV_HIDDEN` visibility on any `GLOBAL/WEAK` defined symbol that is not in the exported symbol set, without changing the binding. This is an in-place modification (only writing the st_other byte per matching entry), with zero overhead.

Supported on ELF targets (Linux, BSD, etc.) and Apple targets (macOS, iOS, etc.). On unsupported targets (Windows), a warning is emitted and the flag has no effect.

**Update**: The rename counterpart (`-Zstaticlib-rename-internal-symbols`) is in rust-lang/rust#156950.

The test code are as follows:

1.a std rust staticlib:
```rust
use std::collections::HashMap;
use std::panic::{catch_unwind, AssertUnwindSafe};

#[no_mangle]
pub extern "C" fn my_add(a: i32, b: i32) -> i32 { a + b }

#[no_mangle]
pub extern "C" fn my_hash_lookup(key: u64) -> u64 {
    let mut map = HashMap::new();
    for i in 0..100u64 { map.insert(i, i.wrapping_mul(2654435761)); }
    *map.get(&key).unwrap_or(&0)
}

pub fn internal_reverse(s: &str) -> String { s.chars().rev().collect() }

#[no_mangle]
pub extern "C" fn my_format_number(n: i32) -> i32 {
    let s = format!("number: {}", n); s.len() as i32
}

#[no_mangle]
pub extern "C" fn my_safe_div(a: i32, b: i32) -> i32 {
    match catch_unwind(AssertUnwindSafe(|| {
        if b == 0 { panic!("division by zero!"); }
        a / b
    })) {
        Ok(result) => result,
        Err(_) => -1,
    }
}

#[no_mangle]
pub extern "C" fn my_uncaught_panic() { panic!("uncaught panic across FFI"); }
```

1.b downstream c program:
```c
extern int my_add(int a, int b);
extern unsigned long my_hash_lookup(unsigned long key);
extern int my_format_number(int n);
extern int my_safe_div(int a, int b);
extern void my_uncaught_panic(void);

int main() {
    int failures = 0;
    if (my_add(10, 20) != 30) failures++;
    if (my_hash_lookup(5) != 5UL * 2654435761UL) failures++;
    if (my_format_number(42) != 10) failures++;
    if (my_safe_div(100, 5) != 20) failures++;
    if (my_safe_div(100, 0) != -1) failures++;
    pid_t pid = fork();
    if (pid == 0) { alarm(5); my_uncaught_panic(); _exit(0); }
    else { waitpid(pid, &status, 0); }
    return failures;
}
```

The test results with different compiler flags(which might cause binary size reduction) are as follows:
1.c result with `-Zstaticlib-hide-internal-symbols`
```
  settings                   OFF        ON  -Zsave     ALL    OFF.dynsym ON.dynsym
  ------------------------------------------------------------------------
  default                 1.7M      1.5M  204K (12%)    1735       5    1730
  lto_thin                616K      584K  33K (5%)     246       5     241
  lto_fat                 525K      525K    0 (0%)       6       5       1
  opt_s                   1.7M      1.5M  204K (12%)    1735       5    1730
  opt_z                   1.7M      1.5M  204K (12%)    1735       5    1730
  lto_thin_z              602K      570K  32K (5%)     246       5     241
  lto_fat_z               514K      514K    0 (0%)       6       5       1
  full                    514K      514K    0 (0%)       6       5       1
```

1.d result with `-Zstaticlib-hide-internal-symbols + -Zstaticlib-rename-internal-symbols`
```
  settings                   OFF        ON  -Zsave     ALL    OFF.dynsym ON.dynsym
  ------------------------------------------------------------------------
  default                 1.7M      1.5M  162K (9%)    1735       5    1730
  lto_thin                616K      599K  18K (2%)     246       5     241
  lto_fat                 525K      535K  -1% (-1%)       6       5       1
  opt_s                   1.7M      1.5M  162K (9%)    1735       5    1730
  opt_z                   1.7M      1.5M  162K (9%)    1735       5    1730
  lto_thin_z              602K      585K  18K (2%)     246       5     241
  lto_fat_z               514K      524K  -1% (-1%)       6       5       1
  full                    514K      523K  -1% (-1%)       6       5       1
```

2.a no_std rust staticlib
```rust
#![no_std]
#![feature(core_intrinsics)]

use core::panic::PanicInfo;

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! { loop {} }

#[no_mangle]
pub extern "C" fn embedded_add(a: i32, b: i32) -> i32 { a.wrapping_add(b) }

#[no_mangle]
pub extern "C" fn embedded_checksum(data: *const u8, len: usize) -> u8 {
    if data.is_null() { return 0; }
    let slice = unsafe { core::slice::from_raw_parts(data, len) };
    let mut sum: u8 = 0;
    for &byte in slice { sum = sum.wrapping_add(byte); }
    sum
}

fn internal_helper() -> i32 { 42 }
#[no_mangle]
pub extern "C" fn call_internal() -> i32 { internal_helper() }

#[no_mangle]
pub extern "C" fn embedded_trigger_abort() { core::intrinsics::abort(); }
```
2.b downstream c program
```c
extern int embedded_add(int a, int b);
extern unsigned char embedded_checksum(const unsigned char *data, unsigned long len);
extern int call_internal(void);
extern void embedded_trigger_abort(void);

int main() {
    int failures = 0;
    if (embedded_add(10, 20) != 30) failures++;
    unsigned char data[] = {1, 2, 3};
    if (embedded_checksum(data, 3) != 6) failures++;
    if (call_internal() != 42) failures++;
    pid_t pid = fork();
    if (pid == 0) { embedded_trigger_abort(); _exit(0); }
    else { waitpid(pid, &status, 0); }
    return failures;
}
```

The test results with different compiler flags(which might cause binary size reduction) are as follows:
2.c result with `-Zstaticlib-hide-internal-symbols`
```
  settings                   OFF        ON  -Zsave     ALL    OFF.dynsym ON.dynsym
  ------------------------------------------------------------------------
  default                 485K      429K  56K (11%)     490       4     486
  lto_thin                180K      180K    0 (0%)       4       4       0
  lto_fat                 179K      179K    0 (0%)       4       4       0
  opt_s                   485K      429K  56K (11%)     490       4     486
  opt_z                   485K      429K  56K (11%)     490       4     486
  lto_thin_z              180K      180K    0 (0%)       4       4       0
  lto_fat_z               179K      179K    0 (0%)       4       4       0
  full                    179K      179K    0 (0%)       4       4       0
```

2.d result with `-Zstaticlib-hide-internal-symbols + -Zstaticlib-rename-internal-symbols`
```
  settings                   OFF        ON  -Zsave     ALL    OFF.dynsym ON.dynsym
  ------------------------------------------------------------------------
  default                 485K      447K  39K (7%)     490       4     486
  lto_thin                180K      189K  -5% (-5%)       4       4       0
  lto_fat                 179K      189K  -5% (-5%)       4       4       0
  opt_s                   485K      448K  38K (7%)     490       4     486
  opt_z                   485K      448K  38K (7%)     490       4     486
  lto_thin_z              180K      189K  -5% (-5%)       4       4       0
  lto_fat_z               179K      189K  -5% (-5%)       4       4       0
  full                    179K      189K  -5% (-5%)       4       4       0
```

Test results show that this compiler option is beneficial for scenarios where LTO cannot be enabled.

r? @bjorn3 @petrochenkov

Implement feature `integer_casts`

Tracking issue: rust-lang/rust#157388

Fix WASI links

…thanBrouwer

Rename `errors.rs` file to `diagnostics.rs` (2/N)

Follow-up of rust-lang/rust#157485.

r? @JonathanBrouwer

Rename `errors.rs` file to `diagnostics.rs` (3/N)

Follow-up of rust-lang/rust#157485.

r? @JonathanBrouwer

Use `mul nuw nsw` in `intrinsics::copy`

Essentially the same as rust-lang/rust#157560, just for `copy` instead of `copy_nonoverlapping`.

> Yeah, in fact both copy and copy_nonoverlapping could use this since we know the result must be at most isize::MAX else it cannot be inbounds.
> ~ rust-lang/rust#157560 (comment)

r? saethlin

…anBrouwer

Suggest comma multiple

Following from rust-lang/rust#157545

If there are multiple missing comma's, suggest fixing all of them in one step to avoid error cascade.

For example:
```
error: attribute items not separated with `,`
   |
LL |     name = "name"
   |                  ^ help: try adding `,` here
```
followed by
```
error: attribute items not separated with `,`
   |
LL |     kind = "static"
   |                    ^ help: try adding `,` here
```
after adding the comma.

Now this becomes one error:
```
error: attribute items not separated with `,`
  --> $DIR/attr-missing-comma.rs:10:18
   |
LL |     name = "name"
   |                  ^
   |
help: try adding `,` here
   |
LL |     name = "name",
   |                  +
help: try adding `,` here
   |
LL |     kind = "static",
   |                    +
```

Letting `lower_lifetime` check `tcx.named_bound_var` & call `re_infer`
just means we now end up passing `lifetime.ident.span` to `re_infer`
instead of the `span` of the trait object type. However,

1. in the case of `LifetimeKind::ImplicitObjectLifetimeDefault`
   `lifetime.ident.span` is actually equal to said span.
2. in the case of `LifetimeKind::Infer` the span now makes more sense;
   consider `dyn Trait + '_` where the span now just contains the `'_`
   not the entire type which is just better.

…nfer`

This makes it really obvious that we're computing object region bounds
for `Infer`, too, not just for `ImplicitObjectLifetimeDefault` which was
really hard to see beforehand. It's unclear to me whether this was
intentional or not, needs investigation.

Introduce method `lower_trait_object_lifetime` to allow usage of early
returns to make the control flow clearer compared to the `unwrap_or_else`.

…nce Option

calling `.cloned()` or `.copied()` on `Option<T>` where `T` is an owned type
emitted "`Option<T>` is not an iterator" with a suggestion to prepend
`.into_iter()`. the suggested code still did not compile: `Option<T>::into_iter()`
yields `T` by value not `&T`, so `.cloned()`/`.copied()` failed again for the
same reason.

`Option<T>` implements `IntoIterator`, which is why the
`impl_into_iterator_should_be_iterator` branch fires. added a guard before it:
when the method is `cloned`/`copied`, the receiver is `Option<T>`, and `T` is a
concrete non-reference type, emit a targeted label pointing at the correct form
(`Option<&T>`) and suggest removing the call instead.

…y 'unused' size_of calls

…uwer

Rollup of 9 pull requests

Successful merges:

 - rust-lang/rust#157599 (`rust-analyzer` subtree update)
 - rust-lang/rust#157298 (Use alternate means of detecting enums in `is_udt`)
 - rust-lang/rust#155338 (Staticlib hide internal symbols)
 - rust-lang/rust#157402 (Implement feature `integer_casts`)
 - rust-lang/rust#157452 (Fix WASI links)
 - rust-lang/rust#157535 (Rename `errors.rs` file to `diagnostics.rs` (2/N))
 - rust-lang/rust#157585 (Rename `errors.rs` file to `diagnostics.rs` (3/N))
 - rust-lang/rust#157588 (Use `mul nuw nsw` in `intrinsics::copy`)
 - rust-lang/rust#157592 (Suggest comma multiple)

Inconsistency happens when subdiagnostic pads the main diagnostic with
an empty source line (aka "|"). Meanwhile the parallel frontend might
bunch subdiagnostics on a single primary diagnostic, removing padding
from some other one.

Revert "Update reproducibly failing tests when parallel frontend is enabled"

This reverts commit f582193.

Apply a test directive format suggested by a reviewer

Bless thine tests

…d in comptime fn

…rgetted at what it does

This reverts commit 32071be.