Rollup of 3 pull requests
Successful merges:
- #59405 (doc: use correct body font URLs)
- #59562 (Changed reference style in dbg macro docs.)
- #59569 (Add book.toml with title to unstable-book doc)
Failed merges:
r? @ghost
Changed reference style in dbg macro docs.
# Description
A continuation of Pull Request #59528 :
- Fixed method of referencing and adjusted the references as suggested by @lzutao
doc: use correct body font URLs
The CSS for the docs homepage (docs.rust-lang.org) was using the wrong
URL for the body font, resulting in the fallback serif font being used,
instead of the desired Source Serif Pro fonts.
(It's worth noting that the CSS for rustdoc's API generation got these URLs right.)
manifest: only include miri on the nightly channel
miri needs to build std with xargo, which doesn't allow stable/beta:
<https://github.com/japaric/xargo/pull/204#issuecomment-374888868>
Therefore, at this time there's no point in making miri available on any
but the nightly channel. If we get a stable way to build `std`, like
[RFC 2663], then we can re-evaluate whether to start including miri,
perhaps still as `miri-preview`.
[RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663
skip dyn keyword lint under macros
This PR is following my own intuition that `rustfix` should never inject bugs into working code (even if that comes at the expense of it failing to fix things that will become bugs).
Fix#56327
Fix invalid DWARF for enums when using ThinLTO
We were setting the same identifier for both the DW_TAG_structure_type
and the DW_TAG_variant_part. This becomes a problem when using ThinLTO
becauses it uses the identifier as a key for a map of types that is used
to delete duplicates based on the ODR, so one of them is deleted as a
duplicate, resulting in invalid DWARF.
The DW_TAG_variant_part isn't a standalone type, so it doesn't need
an identifier. Fix by omitting its identifier.
ODR uniquing is [enabled here](f21dee2c61/src/rustllvm/PassWrapper.cpp (L1101)).
rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`.
The `def_symbol_name` query was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol.
However, #57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step.
So I want to see how much time we're actually saving with this `def_symbol_name` optimization, nowadays.
cc @michaelwoerister
Rollup of 10 pull requests
Successful merges:
- #59376 (RFC 2008: Enum Variants)
- #59453 (Recover from parse error in tuple syntax)
- #59455 (Account for short-hand field syntax when suggesting borrow)
- #59499 (Fix broken download link in the armhf-gnu image)
- #59512 (implement `AsRawFd` for stdio locks)
- #59525 (Whitelist some rustc attrs)
- #59528 (Improve the dbg! macro docs )
- #59532 (In doc examples, don't ignore read/write results)
- #59534 (rustdoc: collapse blanket impls in the same way as normal impls)
- #59537 (Fix OnceWith docstring.)
Failed merges:
r? @ghost
rustdoc: collapse blanket impls in the same way as normal impls
If the rustdoc setting _Auto-hide trait implementations documentation_ is activated (on by default), normal trait implementations are collapsed by default.
Blanket impls on the other hand are not collapsed. I'm not sure whether this is intended, but considering that the blanket impls for `From`, `Into`, `TryFrom`, ... are on every type, it would reduce the documentation bloat if these would also be collapsed when the setting is active.
(I'm not really familiar with the codebase and therefore just copied the code for the normal impl collapsing, but I could deduplicate it into a method, of course, too.)
In doc examples, don't ignore read/write results
Calling `Read::read` or `Write::write` without checking the returned `usize` value is almost always an error. Example code in the documentation should demonstrate how to use the return value correctly. Otherwise, people might copy the example code thinking that it is okay to "fire and forget" these methods.
