Actually closes rust-lang#118079.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…e_userspace_types_send, r=Nilstrieb,dtolnay

Making `User<T>` and `User<[T]>` `Send`

All `User` types in SGX point to owned memory in userspace. Special care is always needed when accessing this memory as it must be assumed that an attacker is always able to change its content. Therefore, we can also easily transfer this memory between thread boundaries.

cc: ``@mzohreva`` ``@vn971`` ``@belalH`` ``@jethrogb``

…=Nilstrieb,dtolnay

chore: Bump compiler_builtins

Actually closes rust-lang#118079.

…er-errors

Add support for shell argfiles

Closes rust-lang/compiler-team#684

…ion, r=fee1-dead

`~const` trait and projection bounds do not imply their non-const counterparts

This PR removes the hack where we install a non-const trait and projection bound for every `const_trait` and `~const` projection bound we have in the AST. It ends up messing up more things than it fixes, see words below.

Fixes rust-lang#119718

cc `@fmease` `@fee1-dead` `@oli-obk`
r? fee1-dead or one of y'all i don't care

---

My understanding is that this hack was added to support the following code:

```rust
pub trait Owo<X = <Self as Uwu>::T> {}

#[const_trait]
pub trait Uwu: Owo {}
```

Which is concretely lifted from in the `FromResidual` and `Try` traits. Since within the param-env of `trait Uwu`, we only know that `Self: ~const Uwu` and not `Self: Uwu`, the projection `<Self as Uwu>::T` is not satsifyable.

This causes problems such as rust-lang#119718, since instantiations of `FnDef` types coming from `const fn` really do **only** implement one of `FnOnce` or `const FnOnce`!

---

In the long-term, I believe that such code should really look something more like:

```rust
#[const_trait]
pub trait Owo<X = <Self as ~const Uwu>::T> {}

#[const_trait]
pub trait Uwu: Owo {}
```

... and that we should introduce some sort of `<T as ~const Foo>::Bar` bound syntax, since due to the fact that `~const` bounds can be present in item bounds, e.g.

```rust
#[const_trait] trait Foo { type Bar: ~const Destruct; }
```

It's easy to see that `<T as Foo>::Bar` and `<T as ~const Foo>::Bar` (or `<T as const Foo>::Bar`) can be distinct types with distinct item bounds!

**Admission**: I know I've said before that I don't like `~const` projection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.

core: panic: fix broken link