consolidate bootstrap docs
With this diff, I tried to consolidate bootstrap documentations and remove the duplicated informations.
Coupled with https://github.com/rust-lang/rustc-dev-guide/pull/1563Resolves#90686
Signed-off-by: ozkanonur <work@onurozkan.dev>
Move code in `rustc_driver` out to a new `rustc_driver_impl` crate to allow pipelining
That adds a `rustc_shared` library which contains all the rustc library crates in a single dylib. It takes over this role from `rustc_driver`. This is done so that `rustc_driver` can be compiled in parallel with other crates. `rustc_shared` is intentionally left empty so it only does linking.
An alternative could be to move the code currently in `rustc_driver` into a new crate to avoid changing the name of the distributed library.
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing.
This would cause the debug assertion ice to trigger.
I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :(
But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? @compiler-errors
This significantly improves performance. For example for the
simple-raytracer benchmark it goes from a 13% improvement over LLVM to
39% improvement over LLVM.
Add a linker argument back to boostrap.py
In https://github.com/rust-lang/rust/pull/101783 I accidentally removed a load-bearing linker argument. This PR adds it back in.
r? jyn514
Rollup of 8 pull requests
Successful merges:
- #106887 (Make const/fn return params more suggestable)
- #107519 (Add type alias for raw OS errors)
- #107551 ( Replace `ConstFnMutClosure` with const closures )
- #107595 (Retry opening proc-macro DLLs a few times on Windows.)
- #107615 (Replace nbsp in all rustdoc code blocks)
- #107621 (Intern external constraints in new solver)
- #107631 (loudly tell people when they change `Cargo.lock`)
- #107632 (Clarifying that .map() returns None if None.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
loudly tell people when they change `Cargo.lock`
It keeps happening that people accidentally commit changes to `Cargo.lock` and then have to be told by a reviewer to undo this. I've also seen cases where PRs are merged that accidentally changed `Cargo.lock` during a rebase.. I figure that purposeful changes to `Cargo.lock` are likely rarer than these accidental ones?
Replace nbsp in all rustdoc code blocks
Based on #106125 by `@dtolnay` — this PR fixes the line wrapping bug.
Fixes#106098. This makes code copyable from rustdoc rendered documentation into a Rust source file.
Retry opening proc-macro DLLs a few times on Windows.
On Windows, the compiler [sometimes](https://users.rust-lang.org/t/error-loadlibraryexw-failed/77603) fails with the message `error: LoadLibraryExW failed` when trying to load a proc-macro crate. The error seems to occur intermittently, similar to https://github.com/rust-lang/rust/issues/86929, however, it seems to be almost impossible to reproduce outside of CI environments and thus very hard to debug. The fact that the error only occurs intermittently makes me think that this is a timing related issue.
This PR is an attempt to mitigate the issue by letting the compiler retry a few times when encountering this specific error (which resolved the issue described in https://github.com/rust-lang/rust/issues/86929).
Make const/fn return params more suggestable
Bumps const item type suggestions to MachineApplicable (fixes#106843), also replaces FnDef with FnPtr items in return type suggestions to make more things suggestable.
r? diagnostics
Edward Shen