rename `TyKind` to `RegionKind` in comment in rustc_middle

Print stderr consistently

Solves https://github.com/rust-lang/rust/issues/96712

I tried to follow what I perceived as the general consensus for error messages in boostrap i.e messages that were ..
* resulting from an Err(...) =>
* literally called as "Error: ...."
* by the end of the block scope forced to run a panic! or process::exit with a guaranteed non-zero error code.

Remove impossible panic note from `Vec::append`

Neither the number of elements in a vector can overflow a `usize`, nor
can the amount of elements in two vectors.

Update jemalloc to v5.3

Now that `jemalloc` version 5.3 has been released, this PR updates `tikv-jemalloc-sys` to the corresponding release.

The crates.io publishing issue seems to have been resolved for the `jemalloc-sys` package, and version 5.3.0 is now also available under the historical name (and should become the preferred crate to be used). Therefore, this PR also switches back to using `jemalloc-sys` instead of  `tikv-jemalloc-sys`.

Move various checks to typeck so them failing causes the typeck result to get tainted

Fixes #69487
fixes #79047

cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant

Fix multiline attributes processing in doctest

Fixes #97440.

It seems like the call to `check_if_attr_is_complete` is not provided with the correct argument: the pending attribute should be passed, while the current line is actually being passed. This causes any attribute with more than 2 lines to fail and produces ICE when running through doctest.

Proc macro tweaks

Various improvements I spotted while looking through the proc macro code.

r? `@EddyB`

The part of it dealing with types obfuscates and makes the code less
concise. This commit removes that part.

Because it's easy to confuse with `bridge`.

There is some non-obvious information required to understand them.

`reverse_encode` isn't necessary to please the borrow checker, it's to
match the ordering done by `reverse_decode`.

So it matches the existing `AttrProcMacro` and `BangProcMacro` types.

Similar to the existing `AttrProcMacro` trait.

This gives the more obvious derive/attr/bang distinction, and reduces
code size slightly.

`u8` is the only type that makes sense for `T`, as demonstrated by the
fact that several impls and functions are hardwired to `Buffer<u8>`.

Rollup of 3 pull requests

Successful merges:

 - #96051 (Use rounding in float to Duration conversion methods)
 - #97066 (rustdoc: Remove `ItemFragment(Kind)`)
 - #97436 (Update `triagebot.toml` for macos ping group)

Failed merges:

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

Update `triagebot.toml` for macos ping group

idk what i'm doing but i saw https://github.com/rust-lang/rust/pull/96392#issuecomment-1138893845

cc: `@thomcc`

rustdoc: Remove `ItemFragment(Kind)`

And stop using `write!` when rendering URL fragments to avoid impossible errors.

Use rounding in float to Duration conversion methods

Closes #96045

libcore: Add `iter::from_generator` which is like `iter::from_fn`, but for coroutines instead of functions

An equally useful little helper.

I didn't follow any of the async-wg work, so I don't know why something like this wasn't added before.

libcore: Add `iter::from_generator` which is like `iter::from_fn`, but for coroutines instead of functions

Optimize position adjustments

A small improvement.

r? `@bjorn3`

Rollup of 3 pull requests

Successful merges:

 - #96033 (Add section on common message styles for Result::expect)
 - #97354 (Updates to browser-ui-test)
 - #97424 (clippy::complexity fixes)

Failed merges:

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

clippy::complexity fixes

clone_on_copy
useless_format
bind_instead_of_map
filter_map_identity
useless_conversion
map_flatten
unnecessary_unwrap

Updates to browser-ui-test

I took the commits from #97317. Since the ubuntu 22.04 version, you either need to use `--no-sandbox` or use another binary to run the GUI tests. I couldn't find out why the chromium used by `browser-ui-test` isn't working anymore on this ubuntu version.

r? `@notriddle`

Add section on common message styles for Result::expect

Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937

~~One thing I haven't decided on yet, should I duplicate this section on `Option::expect`, link to this section, or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs.

I think this section, when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the "expect as precondition" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs, not expected potential failure modes. The "expect as error message" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the "expect as precondition" style of expect message.