Update release notes for 1.64
This PR makes a few updates to the release notes to bring them on-par with the release notes of other releases:
* The wording on some items has been changed to be more consistent and better describe what each change means, rather than using the PR title.
* Items that were also in the compatibility notes have been removed from the other sections, only keeping them in the compat notes.
* Diagnostics and ICE fixes have been removed from the notes.
* The cargo section has been made more consistent.
r? ``@Mark-Simulacrum``
cc ``@rust-lang/release`` ``@joshtriplett``
Add unit test for identifier Unicode emoji diagnostics
Seems current diagnostics has some support for emoji usages, however it seems outdated and incomplete. This adds a simple unit test to showcase the status quo.
Add help for invalid inline argument
Fixes#101712
Removed 1 part of the test as its identical with another one. Do let me know if this is undesirable, so I can revert those changes.
Make `from_waker`, `waker` and `from_raw` unstably `const`
Make
- `Context::from_waker`
- `Context::waker`
- `Waker::from_raw`
`const`.
Also added a small test.
Tone down explanation on RefCell::get_mut
The language around `RefCell::get_mut` is remarkably sketchy and especially to the novice seems to quite strongly discourage using the method ("be cautious", "Also, please be aware", "special circumstances", "usually not what you want"). It was added six years ago in #40634 due to confusion about when to use `get_mut` and `borrow_mut`.
While its signature limits the use-cases for `get_mut`, there is no chance for a safety footgun, and readers can be made aware of `borrow_mut` more softly. I've also just sent a [PR](https://github.com/rust-lang/rust-clippy/issues/9044) to lint situations where `get_mut` could be used to improve ergonomics and performance.
So this PR tones down the language around `get_mut` and also brings it more in line with [`std::sync::Mutex::get_mut()`](https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html#method.get_mut).
`EarlyBinder` prevent misuse
folding a type before substituting is pretty much always wrong and could happen by accident, e.g. see https://github.com/rust-lang/rust/pull/99798#discussion_r968666538
this PR removes the `TypeFoldable` and `TypeVisitable` impl from `EarlyBinder`.
r? types cc `@jackh726`
Distribute json doc
# Overview
We add a new component, `rust-json-docs`, to distribute the JSON version of rustdoc's output for public compiler crates (i.e. `std`, `alloc`, `proc_macro`, `core` and `test`).
As discussed in #101383, we do not bundle this up as part of the existing `rust-docs` component since `rustdoc`'s JSON format is still unstable.
# Open questions / Doubts
I tried my best, but I never touched this codebase and I couldn't find much documentation on how `dist` works - I pattern-matched existing code, which might have led to some non-sensical choices in the eyes of people more familiar with the codebase. In particular, I am not sure if my choice of adding a new config flag is appropriate or if the decision to build/not build the JSON docs is more appropriately gated by one of the existing flags.
Any suggestion is more than welcome.
Closes#101383
Add a codegen test for `slice::from_ptr_range`
I noticed back in #95579 that this didn't optimize as well as it should.
It's better now, after #95837 changed the code in `from_ptr_range` and https://github.com/llvm/llvm-project/issues/54824 was fixed in LLVM 15.
So here's a test to keep it generating the good version.
rustdoc: remove redundant `.location a { font-weight: 500 }`
The `class="location"` element is an h2, either in the sidebar or in the mobile header. Either way, it already has `font-weight: 500`, which the link inside will inherit.
The original version of this rule was added in 9e82fc7ef9b6c8a344dd27583990b02a661af78c. At that time, the location header was rendered as a paragraph with the full path:
9e82fc7ef9/src/librustdoc/html/render.rs (L2080)
Nowadays, it's rendered as a true header, with only the name of the item, and the full path is included in a separate `fqn` header:
98ad6a5519/src/librustdoc/html/render/mod.rs (L1797)
The `class="location"` element is an h2, either in the sidebar or in the
mobile header. Either way, it already has `font-weight: 500`, which the link
inside will inherit.
The original version of this rule was added in
9e82fc7ef9b6c8a344dd27583990b02a661af78c. At that time, the location header
was rendered as a paragraph with the full path:
9e82fc7ef9/src/librustdoc/html/render.rs (L2080)
Nowadays, it's rendered as a true header, with only the name of the item,
and the full path is included in a separate `fqn` header:
98ad6a5519/src/librustdoc/html/render/mod.rs (L1797)
rustdoc: remove unused CSS `.non-exhaustive { margin-bottom }`
This selector was added in 959a13d53e27ca92b59798e6c6737f8249d59a2e to target a `<div class="non-exhaustive">`. With 4edcf6147912e7e4c1f13208d830c3c25e544a8c, the non-exhaustive indicator was changed to a `<details>`, and a separate selector targetting `details.non-exhaustive` was added for it, but the old selector was never removed.
Revert "Copy stage0 binaries into stage0-sysroot"
This reverts PR #101711.
The PR broke the rustc/bootstrap benchmark on rustc-perf, I believe due to the assumption that the stage0 directory exists. Fixing that by just skipping this logic might be reasonable, but I think there's a larger discussion to be had around the right behavior when we don't have a single bin/ directory (when rustc= and cargo= are specified in config.toml). I think it's potentially reasonable to put those binaries (cargo, rustc, rustfmt?) into the bin directory, but for now just want to get us back to a healthy state.
r? `@jyn514` (but would appreciate review from others as this is just a direct revert).
change AccessLevels representation
Part of RFC (https://github.com/rust-lang/rust/issues/48054). This patch implements effective visibility table with basic methods and change AccessLevels table representation according to it.
r? ``@petrochenkov``
Initial version of 1.64 release notes
Needs further expansion on some points, with text that will likely end up in
the blog post as well.
Also adds the release notes from 1.62.1 and 1.63, which weren't present on the
branch.
Rollup of 9 pull requests
Successful merges:
- #101672 (array docs - advertise how to get array from slice)
- #101781 (Extend list of targets that support dyanmic linking for llvm tools)
- #101783 (Improve handing of env vars during bootstrap process)
- #101801 (add note for `layout_of` when query depth overflows)
- #101824 (rustdoc: add test cases for turning ``[Vec<T>]`` into ``[`Vec<T>`]``)
- #101861 (Update stdarch)
- #101873 (Allow building `rust-analyzer-proc-macro-srv` as a standalone tool)
- #101918 (rustdoc: clean up CSS for All Items and All Crates lists)
- #101934 (Continue migration of CSS themes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Allow building `rust-analyzer-proc-macro-srv` as a standalone tool
This PR allows building `rust-analyzer-proc-macro-srv` as a standalone tool via `x b proc-macro-srv-cli` (I thought that `x b rust-analyzer-proc-macro-srv` should work, but it doesn't for some reason...). Also this PR adds a copy of `rust-analyzer-proc-macro-srv` binary to `build/{triple}/{stage}/libexec/` when building `rust-analyzer-proc-macro-srv`, so that r-a can pick it up.
This is useful to make r-a (and I assume Intellij IDEA) to expand macros when using a custom, build from source toolchain.
r? ``@jyn514``
[_zulip thread_](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/How.20to.20fix.20.60UnsupportedABI.60.20for.20custom.20toolchains.3F/near/299040175)
Update stdarch
This pulls in the following changes:
- [Use simd_bitmask intrinsic in a couple of places](9f0928782b)
- [Remove simd_shuffle<n> usage in favor of simd_shuffle](3fd17e4607)
- [Remove late specifiers in __cpuid_count](f1db941633)
- Helps with #101346
- [Use mov and xchg instead of movl(q) and xchgl(q)](3049a31937)
- [Bump cfg-if dependency to 1.0](f305cc83e7)
- [Fix documentation of __m256bh and __m512bh structs](699c093a42)
r? ``@Amanieu``
