Change core::char::{EscapeUnicode, EscapeDefault and EscapeDebug}
structures from using a state machine to computing escaped sequence
upfront and during iteration just going through the characters.

This is arguably simpler since it’s easier to think about having
a buffer and start..end range to iterate over rather than thinking
about a state machine.

This also harmonises implementation of aforementioned iterators and
core::ascii::EscapeDefault struct.  This is done by introducing a new
helper EscapeIterInner struct which holds the buffer and offers simple
methods for iterating over range.

As a side effect, this probably optimises Display implementation for
those types since rather than calling write_char repeatedly, write_str
is invoked once.  On 64-bit platforms, it also reduces size of some of
the structs:

    | Struct                     | Before | After |
    |----------------------------+--------+-------+
    | core::char::EscapeUnicode  |     16 |    12 |
    | core::char::EscapeDefault  |     16 |    12 |
    | core::char::EscapeDebug    |     16 |    16 |

My ulterior motive and reason why I started looking into this is
addition of as_str method to the iterators.  With this change this
will became trivial.  It’s also going to be trivial to implement
DoubleEndedIterator if that’s ever desired.

I think it was left there by mistake after previous refactoring.

Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>

(how did this work before??)

(`StructuralEq` is shallow for some reason...)

…ne_assoc_type

Refactor core::char::EscapeDefault and co. structures

Change core::char::{EscapeUnicode, EscapeDefault and EscapeDebug}
structures from using a state machine to computing escaped sequence
upfront and during iteration just going through the characters.

This is arguably simpler since it’s easier to think about having
a buffer and start..end range to iterate over rather than thinking
about a state machine.

This also harmonises implementation of aforementioned iterators and
core::ascii::EscapeDefault struct.  This is done by introducing a new
helper EscapeIterInner struct which holds the buffer and offers simple
methods for iterating over range.

As a side effect, this probably optimises Display implementation for
those types since rather than calling write_char repeatedly, write_str
is invoked once.  On 64-bit platforms, it also reduces size of some of
the structs:

    | Struct                     | Before | After |
    |----------------------------+--------+-------+
    | core::char::EscapeUnicode  |     16 |    12 |
    | core::char::EscapeDefault  |     16 |    12 |
    | core::char::EscapeDebug    |     16 |    16 |

My ulterior motive and reason why I started looking into this is
addition of as_str method to the iterators.  With this change this
will became trivial.  It’s also going to be trivial to implement
DoubleEndedIterator if that’s ever desired.

…yUwU

Add `ConstParamTy` trait

This is a bit sketch, but idk.
r? `@BoxyUwU`

Yet to be done:
- [x] ~~Figure out if it's okay to implement `StructuralEq` for primitives / possibly remove their special casing~~ (it should be okay, but maybe not in this PR...)
- [ ] Maybe refactor the code a little bit
- [x] Use a macro to make impls a bit nicer

Future work:
- [ ] Actually™ use the trait when checking if a `const` generic type is allowed
- [ ] _Really_ refactor the surrounding code
- [ ] Refactor `marker.rs` into multiple modules for each "theme" of markers

…zer, r=wesleywiser

Stabilize debugger_visualizer

This stabilizes the `debugger_visualizer` attribute (rust-lang#95939).

* Marks the `debugger_visualizer` feature as `accepted`.
* Marks the `debugger_visualizer` attribute as `ungated`.
* Deletes feature gate test, removes feature gate from other tests.

Closes rust-lang#95939

…th-associated-type-bounds, r=spastorino

Fix elaboration with associated type bounds

When computing a trait's supertrait predicates, do not add any associated type *trait* bounds to that list of supertrait predicates. This is because supertrait predicates are expected to have the same `Self` type as the trait.

For example, given:

```rust
trait Foo: Bar<Assoc: Send>
```

Before, we would compute that the supertrait predicates of `T: Foo` are `T: Bar` and `<T as Bar>::Assoc: Send`. However, the last bound is a trait predicate for a totally different type than `T`, and existing code that uses supertrait bounds such as vtable construction, closure fn signature deduction, etc. all rely on the invariant that we have a list of predicates for self type `T`.

Fixes rust-lang#76593

The reason for all the extra diagnostic noise is that we're recomputing predicates with a different filter now. These diagnostics should be deduplicated for any end-user though.

---

This does bring up an interesting question -- is the predicate `<T as Bar>::Assoc: Send` an implied bound of `T: Foo`? Because currently the only bounds implied by a (non-alias) trait are its supertraits. I guess I could fix this too, but it would require even more changes, and I'm inclined to punt this question along.

Remove `all` in target_thread_local cfg

I think it was left there by mistake after the previous refactoring. I just came across it while rebasing to master.

…=compiler-errors

uplift `clippy::clone_double_ref` as `suspicious_double_ref_op`

Split from rust-lang#109842.

r? ``@compiler-errors``

…ete, r=jackh726

Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete

I think they've graduated, since as far as I'm aware, they don't cause compiler crashes or unsoundness anymore.