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
