document some -Z flags as living in the rustc-dev-guide
i was looking for these but didn't find them at first; add a breadcrumb so people know where to look
Update books
## rust-lang/edition-guide
1 commits in 1b1bb49babd65c732468cfa515b0c009bd1d26bc..aa6ce337c0adf7a63e33960d184270f2a45ab9ef
2025-05-20 23:47:34 UTC to 2025-05-20 23:47:34 UTC
- Update references to the `missing_fragment_specifier` lint (rust-lang/edition-guide#376)
## rust-lang/reference
3 commits in acd0231ebc74849f6a8907b5e646ce86721aad76..118fd1f1f0854f50e3ae1fe4b64862aad23009ca
2025-05-20 22:52:38 UTC to 2025-05-20 21:45:13 UTC
- Explain why nested receivers are dyn-incompatible (rust-lang/reference#1822)
- Enable `[canonicalize-issue-links]` and `[no-mentions]` in triagebot (rust-lang/reference#1788)
- Mention the temporary scope of `while let`. (rust-lang/reference#1779)
Add per page TOC in the `rustc` book
This PR adds per page Table of Content (TOC) in the `rustc` book (to be extended in the future to our other books).
The goal is to easy the navigation inside the page by providing quick overview of the page content and our position inside that page.
That functionality is unfortunately not available natively in `mdbook`, which prompted community members to create [mdBook-pagetoc](https://github.com/JorelAli/mdBook-pagetoc/) (which this PR is heavily inspired by). It's "only" a JS file (to handle the TOC) and a CSS file (to handle the margin, colors, screen size, ...), there is no "post-processor" needed (in mdbook sense).
Live preview at: http://urgau.rf.gd/book
r? ```@jieyouxu```
Add an issue template for future-incompatible lints
This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.
Some comments on my choices:
* Added a dedicated section to describe *why* the change is being made. Many existing issues already have this, so let's standardize on it.
* Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
* Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
* I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
* Clearly show the expected progression steps. Several issues already have this.
* Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)
Remove mono item collection strategy override from -Zprint-mono-items
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
Michael Goulet