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`.
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
Move various checks to typeck so them failing causes the typeck result to get tainted
Fixes#69487fixes#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.
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.
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.
