…the self type

…inop

Co-authored-by: Ruby Lazuli <[email protected]>

The working group got renamed

Add documentation about the memory layout of `Cell`

rust-lang#101717 guaranteed the memory layout of `UnsafeCell<T>`.

This property (a guaranteed memory layout) can be useful to have on `Cell<T>` as well.

(Note that `Cell<u8>` [already doesn't trigger the `improper_ctypes` lint](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=34af59ef60b96d8a8bdaec1d52cb5420) since it is `#[repr(transparent)]`).

The concrete use-case is for the crate [`objc2`](https://github.com/madsmtm/objc2) to specify that `Cell<T>` is safe to use as an instance variable when `T` is.

Fixes rust-lang#79303.

---

I'm unsure if we should specify less, for example say that the `Cell` may have extra restrictions on when it may be accessed, or if that's implicit in the (deliberately minimal) way I've worded it here?

…q-on-num-var, r=lcnr

Emit alias-eq when equating numeric var and projection

This doesn't fix everything having to do with projections and infer vars, but it does fix a common case I saw in HIR typeck.

r? `@lcnr`

…pastorino

Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type

We never supported solving `for<'a> fn(&'a ()): Fn(&'a ())` -- I tried to add that support in rust-lang#104929, but iirc `@lcnr` wanted to support this more generally by eagerly instantiating trait predicate binders with placeholders. That never happened due to blockers in the old solver, but we probably shouldn't ICE in any case.

On the bright side, this passes on the new solver :^)

fix(lexer): print whitespace warning for \x0c

- close rust-lang#108275
- discussion: rust-lang#108403

…n-impl, r=petrochenkov

feat: implement better error for manual impl of `Fn*` traits

Fixes rust-lang#39259

cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)

improve readability of winnowing

…hifting, r=BoxyUwU

Don't even try to combine consts with incompatible types

~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~

1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.

Fixes rust-lang#108781

Update triagebot rust-analyzer team mention

The working group got renamed

…ure-default-impl, r=cjgillot

Forbid `#[target_feature]` on safe default implementations

Fixes rust-lang#108646.