The method takes two pointer arguments: one `self` supplying the pointer
value, and a second pointer supplying the metadata.

The new parameter type more clearly reflects the actual requirements.
The provenance of the metadata parameter is disregarded completely.
Using a mutable pointer in the call site can be coerced to a const
pointer while the reverse is not true.

An example of the current use:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```

This could then instead be simplified to:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = uninit.as_ptr().with_metadata_of(&**val);
```

This checks that:

* the handle is a pipe
* the pipe's file name starts with "msys-" or "cygwin-" rather than looking in the full path.

…es in a macro

Slightly tweak comments wrt `lint_overflowing_range_endpoint`

From the review: rust-lang#101986 (comment)

It _seemed_ that the lint was not emitted when the `if` check failed, but _actually_ this happens already in a special case and the lint is emitted outside of this function, if this function doesn't. I've cleared up the code/comments a bit, so it's more obvious :)

r? ```@estebank```

…oss-crate-gat-params, r=GuillaumeGomez

rustdoc: render bounds of cross-crate GAT params

Follow-up to rust-lang#102439.
Render the trait bounds of type parameters of cross-crate (generic) associated types.

`````@rustbot````` label T-rustdoc A-cross-crate-reexports
r? `````@GuillaumeGomez`````

…-in-macro, r=fee1-dead

Allow semicolon after closure within parentheses in macros

rust-lang#88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in rust-lang#103222.

This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro?

I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place...

Fixes rust-lang#103222.

…htriplett

(rust-lang#102929) Implement `String::leak` (attempt 2)

Implementation of `String::leak` (rust-lang#102929)

ACP: rust-lang/libs-team#109

Supersedes rust-lang#102941 (see previous reviews there)

```@rustbot``` label +T-libs-api -T-libs

…homcc

Add a forgotten check for NonNull::new_unchecked's precondition

Looks like I forgot this function a while ago in rust-lang#92686

r? ```@thomcc```

…nter_argument, r=dtolnay

Adjust argument type for mutable with_metadata_of (rust-lang#75091)

The method takes two pointer arguments: one `self` supplying the pointer value, and a second pointer supplying the metadata.

The new parameter type more clearly reflects the actual requirements. The provenance of the metadata parameter is disregarded completely. Using a mutable pointer in the call site can be coerced to a const pointer while the reverse is not true.

In some cases, the current parameter type can thus lead to a very slightly confusing additional cast. [Example](HeroicKatora/static-alloc@cad9377).

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```

This could then instead be simplified to:

```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;

let ptr = uninit.as_ptr().with_metadata_of(&**val);
```

Tracking issue: rust-lang#75091

``@dtolnay`` you're reviewed rust-lang#95249, would you mind chiming in?

Reduce false positives in msys2 detection

Currently msys2 will be detected by getting the file path and looking to see if it contains the substrings "msys-" and "-ptr" (or "cygwin-" and "-pty"). This risks false positives, especially with filesystem files and if `GetFileInformationByHandleEx` returns a [full path](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile#remarks).

This PR adds a check to see if the handle is a pipe before doing the substring search. Additionally, for "msys2-" or "cygwin-" it only checks if the file name starts with the substring rather than looking at the whole path.