Update rust-installer to limit memory use
See https://github.com/rust-lang/rust-installer/pull/98 -- on a many-core machine, the xz memory for so many threads is more than a 32-bit process can handle. The xz stream is now limited to 8 threads.
r? @alexcrichton
rustbuild: allow disabling deny(warnings) for bootstrap
When deny-warnings is not specified or set to true, the behaviour is the same as before.
When deny-warnings is set to false, warnings are now allowed
Fixes#63911
Validation: check raw wide pointer metadata
While I was at it, I also added a missing check for slices not to be too big.
r? @oli-obk
Fixes https://github.com/rust-lang/miri/issues/918
resolve: Block expansion of a derive container until all its derives are resolved
So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248).
The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468).
So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved.
After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives.
Unblocks https://github.com/rust-lang/rust/pull/63468
r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248)
cc @c410-f3r
Rollup of 11 pull requests
Successful merges:
- #63811 (Correctly suggest adding bounds to `impl Trait` argument)
- #63933 (Resolve some small issues related to #63580)
- #63938 (or-pattern: fix typo in error message)
- #63945 (Recover `mut $pat` and other improvements)
- #63958 (const_prop: only call error_to_const_error if we are actually showing something)
- #63961 (Add Option<Span> to `require_lang_item`)
- #63963 (remove the reference to __cxa_thread_atexit_impl)
- #63965 (Prevent syntax error in LD linker version script)
- #63968 (rustc_apfloat: make the crate #![no_std] explicitly.)
- #63970 (Notify me (flip1995) when Clippy toolstate changes)
- #63980 (add missing `#[repr(C)]` on the Slices union)
Failed merges:
- #63989 (Add Yaah to clippy toolstain notification list)
r? @ghost
Notify me (flip1995) when Clippy toolstate changes
I want in on the fun 🎉
Also friendly ping @llogiq @mcarton: Since you two aren't _that_ active on the Clippy repo anymore, do you still want to get pinged on Clippy toolstate changes?
r? @oli-obk
Prevent syntax error in LD linker version script
As discussed in #63925, there is an edge case in which an invalid LD version script is generated when building a `cdylib` with no exported symbols. This PR makes a slight modification to the LD version script generation by first checking to see if any symbols need to be exported. If not, the `global` section of the linker script is simply omitted, and the syntax error is averted.
const_prop: only call error_to_const_error if we are actually showing something
This makes `RUSTC_CTFE_BACKTRACE` useful again.
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/63439
Recover `mut $pat` and other improvements
- Recover on e.g. `mut Foo(x, y)` and suggest `Foo(mut x, mut y)`. Fixes https://github.com/rust-lang/rust/issues/63764.
- Recover on e.g. `let mut mut x;`
- Recover on e.g. `let keyword` and `let keyword(...)`.
- Cleanups in `token.rs` with `fn is_non_raw_ident_where` and friends.
Resolve some small issues related to #63580
This resolves some feedback left on #63580 after it was merged:
- Adds documentation to `mir::Static` and `mir::StaticKind`
- Simplifies `maybe_get_optimized_mir()` and `maybe_get_promoted_mir()`
cc @bjorn3 @RalfJung
Improve Rustdoc's handling of procedural macros
Fixes#58700Fixes#58696Fixes#49553Fixes#52210
This commit removes the special rustdoc handling for proc macros, as we can now
retrieve their span and attributes just like any other item.
A new command-line option is added to rustdoc: `--crate-type`. This takes the same options as rustc's `--crate-type` option. However, all values other than `proc-macro` are treated the same. This allows Rustdoc to enable 'proc macro mode' when handling a proc macro crate.
In compiletest, a new 'rustdoc-flags' option is added. This allows us to
pass in the '--proc-macro-crate' flag in the absence of Cargo.
I've opened [an additional PR to Cargo](https://github.com/rust-lang/cargo/pull/7159) to support passing in this flag.
These two PRS can be merged in any order - the Cargo changes will not
take effect until the 'cargo' submodule is updated in this repository.
Save crate filtering on rustdoc
Fixes#62929.
I added a hashmap and a hash encoding for the current crate list in case you have multiple crates handling on a same website (who talked about docs.rs?!). Like that, for each context, you have the filter crate selected.
r? @QuietMisdreavus
debuginfo: give unique names to closure and generator types
Closure types have been moved to the namespace where they
are defined, and both closure and generator type names now
include the disambiguator.
This fixes an exception when lldb prints nested closures.
Fixes#57822
I haven't included the `DW_AT_artificial` changes discussed in #57822 because they make the output worse IMO, but I can easily add these if still required. For example, for the new test case the output is now:
```
(lldb) p g
(issue_57822::main::closure-1) $1 = closure-1(closure(1))
```
but adding `DW_AT_artificial` changes this to:
```
(lldb) p g
(issue_57822::main::closure-1) $0 = closure-1 {
}
```
Note that nested generators didn't cause the exception. I haven't determined why, but I think it makes sense to add the disambiguator for them too. It feels like we still don't really understand why closures were causing an error though.
r? @michaelwoerister
When deny-warnings is not specified or set to true, the behaviour is the same as before.
When deny-warnings is set to false, warnings are now allowed
Fixes#63911
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
