* add test from issue rust-lang/portable-simd#253

diagnostics: single colon within `<>` probably, not type ascription

Fixes #94812

Return early to fix ICE

This fixes #94627, ICE happens because compiler tries to suggest constraining type parameter but the only constraint is implicit `std::Sized` one, so it gets removed and there is nothing to suggest resulting in ICE.

Co-authored-by: NCamille Gillot <gillot.camille@gmail.com>

Fix ICE when using Box<T, A>, again

Sequel to #94043, fixes #94835.

diagnostics: do not spurriously claim something is "not an iterator"

Fixes a minor regression caused by #94746, where `iter::Filter` is spurriously declared "not an iterator."

Rollup of 3 pull requests

Successful merges:

 - #94150 (rustdoc-json: Include GenericParamDefKind::Type::synthetic in JSON)
 - #94833 ([2/2] Implement macro meta-variable expression)
 - #94863 (Remove redundant slicing of whole ranges in `bootstrap`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Remove redundant slicing of whole ranges in `bootstrap`

Found with `clippy::redundant_slicing`.

[2/2] Implement macro meta-variable expression

Final part of https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295

r? `@petrochenkov`

rustdoc-json: Include GenericParamDefKind::Type::synthetic in JSON

The rustdoc JSON for

```
pub fn f(_: impl Clone) {}
```

will effectively be

```
pub fn f<impl Clone: Clone>(_: impl Clone) {}
```

where a synthetic generic parameter called `impl Clone` with generic trait bound
`Clone` is added to the function declaration.

The generated HTML filters out these generic parameters by doing
`self.params.iter().filter(|p| !p.is_synthetic_type_param())`, because the
synthetic generic paramter is not of interest to regular users.

For the same reason, we should expose whether or not a generic parameter is
synthetic or not also in the rustdoc JSON, so that rustdoc JSON clients can also
have the option to hide syntehtic generic parameters.

`@rustbot` modify labels: +A-rustdoc-json

Improve `AdtDef` interning.

This commit makes `AdtDef` use `Interned`. Much of the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.

r? `@fee1-dead`

Fixes a minor regression caused by #94746, where iter::Filter is
spurriously declared "not an iterator."

Fixes #94812

Rollup of 7 pull requests

Successful merges:

 - #87618 (Add missing documentation for std::char types)
 - #94769 (Collapse blanket and auto-trait impls by default)
 - #94798 (`parse_tt` refactorings)
 - #94818 (Rename `IntoFuture::Future` to `IntoFuture::IntoFuture`)
 - #94827 (CTFE/Miri: detect out-of-bounds pointers in offset_from)
 - #94838 (Make float parsing docs more comprehensive)
 - #94839 (Suggest using double colon when a struct field type include single colon)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Suggest using double colon when a struct field type include single colon

#92685

Make float parsing docs more comprehensive

I was working on some code with some specialized restrictions on float parsing. I noticed the doc comments for `f32::from_str` and `f64::from_str` were missing several cases of valid inputs that are otherwise difficult to discover without looking at source code.

I'm not sure if the doc comments were initially intended to contain a comprehensive description of valid inputs, but I figured it's useful to include these extra cases for reference.

CTFE/Miri: detect out-of-bounds pointers in offset_from

Also I became uneasy with aggressively doing `try_to_int` here -- this will always succeed on Miri, leading to the wrong codepath being taken. We should rather try to convert them both to pointers, and use the integer path as a fallback, so that's what I implemented now.

Hiding whitespaces helps with the diff.

Fixes https://github.com/rust-lang/miri/issues/1950

r? ``@oli-obk``

Rename `IntoFuture::Future` to `IntoFuture::IntoFuture`

Ref: https://github.com/rust-lang/rust/issues/67644#issuecomment-1051401459

This renames `IntoFuture::Future` to `IntoFuture::IntoFuture`. This adds the `Into*` prefix to the associated type, similar to the [`IntoIterator::IntoIter`](https://doc.rust-lang.org/std/iter/trait.IntoIterator.html#associatedtype.IntoIter) associated type. It's my mistake we didn't do so in the first place. This fixes that and brings the two closer together. Thanks!

### References
__`IntoIterator` trait def__
```rust
pub trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item = Self::Item>;
    fn into_iter(self) -> Self::IntoIter;
}
```
__`IntoFuture` trait def__
```rust
pub trait IntoFuture {
    type Output;
    type IntoFuture: Future<Output = Self::Output>; // Prior to this PR: `type Future:`
    fn into_future(self) -> Self::IntoFuture;
}
```

cc/ `@eholk` `@rust-lang/wg-async`

`parse_tt` refactorings

Some readability improvements.

r? ``@petrochenkov``

Collapse blanket and auto-trait impls by default

Blocked on #94740 (the two first commits come from it).

This behaviour was changed in https://github.com/rust-lang/rust/pull/88490 and apparently wasn't caught since then.

You can test it [here](https://rustdoc.crud.net/imperio/collapsed-by-default/test_docs/struct.Foo.html#blanket-implementations).

r? ``@notriddle``

Add missing documentation for std::char types

Use MaybeUninit in VecDeque to remove the undefined behavior of slice
Signed-off-by: NJmPotato <ghzpotato@gmail.com>

Ref https://github.com/rust-lang/rust/issues/74189. Adjust the code to follow the [doc.rust-lang.org/reference/behavior-considered-undefined.html](https://doc.rust-lang.org/reference/behavior-considered-undefined.html).

* Change the return type of `buffer_as_slice` from `&[T]` to `&[MaybeUninit<T>]`.
* Add some corresponding safety comments.

Benchmark results:

master 8d6f5275

```rust
test collections::vec_deque::tests::bench_pop_back_100       ... bench:          47 ns/iter (+/- 1)
test collections::vec_deque::tests::bench_pop_front_100      ... bench:          50 ns/iter (+/- 4)
test collections::vec_deque::tests::bench_push_back_100      ... bench:          69 ns/iter (+/- 10)
test collections::vec_deque::tests::bench_push_front_100     ... bench:          72 ns/iter (+/- 6)
test collections::vec_deque::tests::bench_retain_half_10000  ... bench:     145,891 ns/iter (+/- 7,975)
test collections::vec_deque::tests::bench_retain_odd_10000   ... bench:     141,647 ns/iter (+/- 3,711)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench:     120,132 ns/iter (+/- 4,078)
```

This PR

```rust
test collections::vec_deque::tests::bench_pop_back_100       ... bench:          48 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_pop_front_100      ... bench:          51 ns/iter (+/- 3)
test collections::vec_deque::tests::bench_push_back_100      ... bench:          73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_push_front_100     ... bench:          73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_retain_half_10000  ... bench:     131,796 ns/iter (+/- 5,440)
test collections::vec_deque::tests::bench_retain_odd_10000   ... bench:     137,563 ns/iter (+/- 3,349)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench:     128,815 ns/iter (+/- 3,289)
```

Change several HashMaps to IndexMap to improve incremental hashing performance

Stable hashing hash maps in incremental mode takes a lot of time, especially for some benchmarks like `clap`. As noted by `@Mark-Simulacrum` [here](https://github.com/rust-lang/rust/pull/89404#issuecomment-950043892), this cost could be reduced by replacing some hash maps by indexmaps.

I gathered some statistics and found several hash maps that took a lot of time to hash and replaced them by indexmaps. However, in order for this to work, we need to make sure that these indexmaps have deterministic insertion order. These three are used only in visitors as far as I can see, which seems deterministic. Can we enforce this somehow? Or should some explaining comment be included for these maps?

Rollup of 5 pull requests

Successful merges:

 - #93283 (Fix for localized windows editions in testcase fn read_link() Issue#93211)
 - #94592 (Fallback to top-level config.toml if not present in current directory, and remove fallback for env vars and CLI flags)
 - #94776 (Optimize ascii::escape_default)
 - #94840 (update `replace_bound_vars_with_placeholders` doc comment)
 - #94842 (Remove unnecessary try_opt for operations that cannot fail)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Remove unnecessary try_opt for operations that cannot fail

As indicated in the added comments, some operation cannot overflow, so using `try_opt!` for them is unnecessary.

update `replace_bound_vars_with_placeholders` doc comment

Optimize ascii::escape_default

`ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data).
After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters, so that's what this PR implements

The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!

Fallback to top-level config.toml if not present in current directory, and remove fallback for env vars and CLI flags

This preserves the behavior where x.py will only give a hard error on a missing config file if it was configured through `--config` or RUST_BOOTSTRAP_CONFIG. It also removes the top-level fallback for everything except the default path; presumably if you're passing the path explicitly, you expect it to be exactly there and don't want to look in the root directory.

Fixes https://github.com/rust-lang/rust/issues/94589.

Fix for localized windows editions in testcase fn read_link() Issue#93211

This PR aims to fix the issue with localized windows versions that do not necessarily have the folder "Documents and settings" in English.

The idea was provided by `@the8472.` We check if the "CI" environment variable is set, then we always check for the "Documents and Settings"-folder, otherwise we check if the folder exists on the local machine, and if not we skip this assert.

Resoles #93211.