bootstrap: Memoize the LLVM rebuild hash to avoid very slow `x check`
Recently I've encountered a massive regression in the performance of re-running `x check` after making no changes.
It used to take around 2 seconds, and now it takes 20-30 seconds. That's quite a hassle when r-a runs it every time I save.
After some poking around, what I've found is that each individual call to `generate_smart_stamp_hash` doesn't take a particularly long time (around 0.5 sec), but it gets called dozens of times during `x check`, and that seems to be what's adding up to 20-30 seconds.
---
https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Massive.20regression.20in.20no-op.20.60x.20check.60
cc `@onur-ozkan`
skip {tidy,compiletest,rustdoc-gui} based tests for `DocTests::Only`
As use of `--doc` with `x test` is intended for running doc-tests only, executing compiletest, tidy or rustdoc-gui based tests considered as an incorrect behavior from bootstrap. This change fixes that.
rustdoc: Remove space from fake-variadic fn ptr impls
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
I don't think we usually have spaces there, so it looks weird.
cc `@notriddle` since you added the space in https://github.com/rust-lang/rust/pull/98180 (or rather, added the feature with a space included).
Eagerly compute output_filenames
It can be computed before creating TyCtxt. Previously the query would also write the dep info file, which meant that the output filenames couldn't be accessed before macro expansion is done. The dep info file writing is now done as a separate non-query function. The old query was always executed again anyways due to depending on the HIR.
Also encode the output_filenames in rlink files to ensure `#![crate_name]` affects the linking stage when doing separate compiling and linking using `-Zno-link`/`-Zlink-only`.
Move `implied_bounds_in_impls` back to complexity
This lint was originally in the complexity category when I PR'd it. It was then moved to nursery by me due to a number of issues (a false positive, an invalid suggestion and an ICE), but that was probably an overreaction and all of the issues were fixed quickly after.
This is a useful lint imo and there hasn't been any issues with it in a few months, so I say we should give it another try and move it back to complexity.
I did a lintcheck run on the top 400 crates and all of them are legitimate, with 18 warnings. Most of them are from anstyle having a `impl Display + Copy + Clone` return type, or the bitvec crate with a return type like `impl Iterator + DoubleEndedIterator`.
changelog: Move [`implied_bounds_in_impls`] to `complexity` (Now warn-by-default)
[#11867](https://github.com/rust-lang/rust-clippy/pull/11867)
Fix `box_default` behaviour with empty `vec![]` coming from macro arg
Fix#11868
changelog: [`box_default`]: do not warn on `Box::new(vec![])` if the `vec![]` comes from a macro argument
Non null convenience ops
Based on https://github.com/rust-lang/libs-team/issues/251.
I went through all of the methods on `*mut` and added every method, which does not require additional safety conditions, to `NonNull`. (exceptions: `guaranteed_eq`, `guaranteed_ne`, `with_metadata_of`, it's unclear if they are useful here...)
I'm also not sure what types should the "second pointer parameter" be. `*mut`/`*const` might be more permissible, but given that `NonNull` doesn't coerce to them, it might also be annoying. For now I chose the "use `NonNull` everywhere" path, but I'm not sure it's the correct one...
<sub>I'm eepy, so I probably messed up somewhere while copying...</sub>
cc `@scottmcm`
r? libs-api
