Rollup of 11 pull requests
Successful merges:
- #75853 (Use more intra-doc-links in `core::fmt`)
- #75928 (Remove trait_selection error message in specific case)
- #76329 (Add check for doc alias attribute at crate level)
- #77219 (core::global_allocator docs link to std::alloc::GlobalAlloc)
- #77395 (BTreeMap: admit the existence of leaf edges in comments)
- #77407 (Improve build-manifest to work with the improved promote-release)
- #77426 (Include scope id in SocketAddrV6::Display)
- #77439 (Fix missing diagnostic span for `impl Trait` with const generics, and add various tests for `min_const_generics` and `const_generics`)
- #77471 (BTreeMap: refactoring around edges, missed spots)
- #77512 (Allow `Abort` terminators in all const-contexts)
- #77514 (Replace some once(x).chain(once(y)) with [x, y] IntoIter)
Failed merges:
r? `@ghost`
Allow `Abort` terminators in all const-contexts
We never unwind during const-eval, so we basically have these semantics already. Also I just figured out that these only appear along the cleanup path, which doesn't get const-checked. In other words, this doesn't actually change behavior: the `check-pass` test I added compiles just fine on nightly.
r? @RalfJung
cc @rust-lang/wg-const-eval
Improve build-manifest to work with the improved promote-release
This PR makes some changes to build-manifest to have it work better with the other improvements I'm making to [promote-release](https://github.com/rust-lang/promote-release).
A new way to invoke the tool was added: `./x.py run src/tools/build-manifest`. The new invocation disables the generation of `.sha256` files and the generation of GPG signatures, as those steps are not tied to the Rust version we're building the manifest of: handling them in `promote-release` will improve the maintenability of our release process. Invocations through the old command (`./x.py dist hash-and-sign`) are referred inside the source code as "legacy". The new invocation also enables internal parallelism, disabled on legacy to avoid overloading our old server.
Improvements were also made on how the checksums included in the manifest are generated:
* The manifest is first generated with placeholder checksums, and then a function walks through the manifes and calculates only the needed hashes. Before this PR, all the hashes were calculated beforehand, including the hashes of unused files.
* Calculating the hashes is now done in parallel with rayon, to better utilize all the available disk bandwidth.
* The `sha2` crate is now used instead of the `sha256sum` CLI tool: this avoids the overhead of calling another process, but more importantly enables hardware acceleration whenever available (the `sha256sum` CLI tool doesn't support it at all).
r? @Mark-Simulacrum
This PR is best reviewed commit-by-commit.
Remove trait_selection error message in specific case
In the case that a trait is not implemented for an ADT with type errors, cancel the error.
Fixes#75627
Hint the maximum length permitted by invariant of slices
One of the safety invariants of references, and in particular of references to slices, is that they may not cover more than `isize::MAX` bytes. The unsafe `from_raw_parts` constructors of slices explicitly requires the caller to guarantee this fact. Violating it would also be UB with regards to the semantics of generated llvm code.
This effectively bounds the length of a (non-ZST) slice from above by a compile time constant. But when the length is loaded from a function argument it appears llvm is not aware of this requirement. The additional value range assertions allow some further elision of code branches, including overflow checks, especially in the presence of artithmetic on the indices.
This may have a performance impact, adding more code to a common method but allowing more optimization. I'm not quite sure, is the Rust side of const-prop strong enough to elide the irrelevant match branches?
Fixes: #67186
Uses assume to check the length against a constant upper bound. The
inlined result then informs the optimizer of the sound value range.
This was tried with unreachable_unchecked before which introduces a
branch. This has the advantage of not being executed in sound code but
complicates basic blocks. It resulted in ~2% increased compile time in
some worst cases.
Add a codegen test for the assumption, testing the issue from #67186
Only use Fira Sans for the first `td` in item lists
Fixes#77516.
Fixes an issue where links in the one-line version of an item's docs
would be in Fira Sans, while the rest would be in a serifed font.
Change DocFragments from enum variant fields to structs with a nested enum
This makes the code a lot easier to work with. It also makes it easier
to add new fields without updating each variant and `match`
individually.
- Name the `Kind` variant after `DocFragmentKind` from `collapse_docs`
- Remove unneeded impls
Progress towards https://github.com/rust-lang/rust/issues/77254.
r? @GuillaumeGomez
This was fixed with the upgrade to LLVM 11 in #73526.
It seems extremely unlikey that this exact issue will ever reoccur,
since slight modifications to the code caused the crash to stop
happening. However, it can't hurt to have a test for it.
Implement Make `handle_alloc_error` default to panic (for no_std + liballoc)
Related: https://github.com/rust-lang/rust/issues/66741
Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
Improve rustdoc error for failed intra-doc link resolution
The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.
Also suggested importing the item.
r? @jyn514
Add some regression tests
Closes#66501Closes#68951Closes#72565Closes#74244Closes#75299
The first issue is fixed in 1.43.0, other issues are fixed in the recent nightly.
Use `tracing` spans to trace the entire MIR interp stack
r? @RalfJung
While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame.
If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level.
cc @hawkw
This makes the code a lot easier to work with. It also makes it easier
to add new fields without updating each variant and `match`
individually.
- Name the `Kind` variant after `DocFragmentKind` from `collapse_docs`
- Remove unneeded impls
This matches Cargo behavior and avoids the (somewhat expensive) double checking,
as well as the unfortunate duplicate error messages (#76822,
rust-lang/cargo#5128).
Remove --cfg dox from rustdoc.rs
This was added in https://github.com/rust-lang/rust/pull/53076 because
several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`).
I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think
this is now safe to remove.
r? `@Mark-Simulacrum`
cc `@QuietMisdreavus` :)
