When spawning Commands, the path we use can end up being queried using `env::current_exe` (or the equivalent in other languages). Not all applications handle these paths properly therefore we should have a stronger preference for non-verbatim paths when spawning processes.

…ceiver

Tests that messages are immediately dropped once the last receiver is destroyed.

… panics

…=joshtriplett

Windows: make `Command` prefer non-verbatim paths

When spawning Commands, the path we use can end up being queried using `env::current_exe` (or the equivalent in other languages). Not all applications handle these paths properly therefore we should have a stronger preference for non-verbatim paths when spawning processes.

…, r=Amanieu

Drop all messages in bounded channel when destroying the last receiver

Fixes rust-lang#107466 by splitting the `disconnect` function for receivers/transmitters and dropping all messages in `disconnect_receivers` like the unbounded channel does. Since all receivers must be dropped before the channel is, the messages will already be discarded at that point, so the `Drop` implementation for the channel can be removed.

``@rustbot`` label +T-libs +A-concurrency

…enkov

fix: modify the condition that `resolve_imports` stops

close rust-lang#97534

…r, r=BoxyUwU

Constrain const vars to error if const types are mismatched

When equating two consts of different types, if either are const variables, constrain them to the correct const error kind.

This helps us avoid "successfully" matching a const against an impl signature but leaving unconstrained const vars, which will lead to incremental ICEs when we call const-eval queries during const projection.

Fixes rust-lang#109296

The second commit in the stack fixes a regression in the first commit where we end up mentioning `[const error]` in an impl overlap error message. I think the error message changes for the better, but I could implement alternative strategies to avoid this without delaying the overlap error message...

r? `@BoxyUwU`

…tebank

Avoid ICE of attempt to add with overflow in emitter

Fixes rust-lang#109396
r? ```@estebank```

…g_lit, r=petrochenkov

Refactor `handle_missing_lit`.

A small code readability improvement.

r? ```@petrochenkov```

…piler-errors

Only implement Fn* traits for extern "Rust" safe function pointers and items

Since calling the function via an `Fn` trait will assume `extern "Rust"` ABI and not do any safety checks, only safe `extern "Rust"` function can implement the `Fn` traits. This syncs the logic between the old solver and the new solver.

r? `@compiler-errors`

…er-errors

Do not suggest bounds restrictions for synthesized RPITITs

Before this PR we were getting ...

```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
 --> tests/ui/async-await/in-trait/missing-send-bound.rs:5:12
  |
5 | #![feature(async_fn_in_trait)]
  |            ^^^^^^^^^^^^^^^^^
  |
  = note: see issue rust-lang#91611 <rust-lang#91611> for more information
  = note: `#[warn(incomplete_features)]` on by default

error: future cannot be sent between threads safely
  --> tests/ui/async-await/in-trait/missing-send-bound.rs:17:20
   |
17 |     assert_is_send(test::<T>());
   |                    ^^^^^^^^^^^ future returned by `test` is not `Send`
   |
   = help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
  --> tests/ui/async-await/in-trait/missing-send-bound.rs:13:5
   |
13 |     T::bar().await;
   |     ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
  --> tests/ui/async-await/in-trait/missing-send-bound.rs:21:27
   |
21 | fn assert_is_send(_: impl Send) {}
   |                           ^^^^ required by this bound in `assert_is_send`
help: consider further restricting the associated type
   |
16 | fn test2<T: Foo>() where impl Future<Output = ()>: Send {
   |                    ++++++++++++++++++++++++++++++++++++

error: aborting due to previous error; 1 warning emitted
```

and we want this output ...

```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
  --> $DIR/missing-send-bound.rs:5:12
   |
LL | #![feature(async_fn_in_trait)]
   |            ^^^^^^^^^^^^^^^^^
   |
   = note: see issue rust-lang#91611 <rust-lang#91611> for more information
   = note: `#[warn(incomplete_features)]` on by default

error: future cannot be sent between threads safely
  --> $DIR/missing-send-bound.rs:17:20
   |
LL |     assert_is_send(test::<T>());
   |                    ^^^^^^^^^^^ future returned by `test` is not `Send`
   |
   = help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
  --> $DIR/missing-send-bound.rs:13:5
   |
LL |     T::bar().await;
   |     ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
  --> $DIR/missing-send-bound.rs:21:27
   |
LL | fn assert_is_send(_: impl Send) {}
   |                           ^^^^ required by this bound in `assert_is_send`

error: aborting due to previous error; 1 warning emitted
```

r? `@compiler-errors`