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.
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
Fix suggestion for coercing Option<&String> to Option<&str>
Fixes#107604
This also makes the diagnostic `MachineApplicable`, and runs `rustfix` to check we're not producing incorrect code.
``@rustbot`` label +A-diagnostics
Don't cause a cycle when formatting query description that references a FnDef
When a function returns `-> _`, we use typeck to compute what the resulting type of the body _should_ be. If we call another query inside of typeck and hit a cycle error, we attempt to report the cycle error which requires us to compute all of the query descriptions for the stack.
However, if one of the queries in that cycle has a query description that references this function as a FnDef type, we'll cause a *second* cycle error from within the cycle error reporting code, since rendering a FnDef requires us to compute its signature. This causes an unwrap to ICE, since during the *second* cycle reporting code, we try to look for a job that isn't in the active jobs list.
We can avoid this by using `with_no_queries!` when computing these query descriptions.
Fixes#107089
The only drawback is that the rendering of opaque types in cycles regresses a bit :| I'm open to alternate suggestions about how we may handle this...
Emit warnings on unused parens in index expressions
Fixes: #96606.
I am not sure what the best term for "index expression" is. Is there a better term we could use?
Autotrait bounds on dyn-safe trait methods
This PR is a successor to #106604 implementing the approach encouraged by https://github.com/rust-lang/rust/pull/106604#issuecomment-1387353737.
**I propose making it legal to use autotraits as trait bounds on the `Self` type of trait methods in a trait object.** https://github.com/rust-lang/rust/issues/51443#issuecomment-1374847313 justifies why this use case is particularly important in the context of the async-trait crate.
```rust
#![feature(auto_traits)]
#![deny(where_clauses_object_safety)]
auto trait AutoTrait {}
trait MyTrait {
fn f(&self) where Self: AutoTrait;
}
fn main() {
let _: &dyn MyTrait;
}
```
Previously this would fail with:
```console
error: the trait `MyTrait` cannot be made into an object
--> src/main.rs:7:8
|
7 | fn f(&self) where Self: AutoTrait;
| ^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #51443 <https://github.com/rust-lang/rust/issues/51443>
note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
--> src/main.rs:7:8
|
6 | trait MyTrait {
| ------- this trait cannot be made into an object...
7 | fn f(&self) where Self: AutoTrait;
| ^ ...because method `f` references the `Self` type in its `where` clause
= help: consider moving `f` to another trait
```
In order for this to be sound without hitting #50781, **I further propose that we disallow handwritten autotrait impls that apply to trait objects.** Both of the following were previously allowed (_on nightly_) and no longer allowed in my proposal:
```rust
auto trait AutoTrait {}
trait MyTrait {}
impl AutoTrait for dyn MyTrait {} // NOT ALLOWED
impl<T: ?Sized> AutoTrait for T {} // NOT ALLOWED
```
(`impl<T> AutoTrait for T {}` remains allowed.)
After this change, traits with a default impl are implemented for a trait object **if and only if** the autotrait is one of the trait object's trait bounds (or a supertrait of a bound). In other words `dyn Trait + AutoTrait` always implements AutoTrait while `dyn Trait` never implements AutoTrait.
Fixes https://github.com/dtolnay/async-trait/issues/228.
r? `@lcnr`
Don't generate unecessary `&&self.field` in deriving Debug
Since unsized fields may only be the last one in a struct, we only need to generate a double reference (`&&self.field`) for the final one.
cc `@nnethercote`
ast: Optimize list and value extraction primitives for attributes
It's not necessary to convert the whole attribute into a meta item to extract something specific.
Rollup of 6 pull requests
Successful merges:
- #106575 (Suggest `move` in nested closure when appropriate)
- #106805 (Suggest `{var:?}` when finding `{?:var}` in inline format strings)
- #107500 (Add tests to assert current behavior of large future sizes)
- #107598 (Fix benchmarks in library/core with black_box)
- #107602 (Parse and recover from type ascription in patterns)
- #107608 (Use triple rather than arch for fuchsia test-runner)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use triple rather than arch for fuchsia test-runner
This allows the user of the test-runner script to specify a full triple rather than just an architecture which helps with the transition from the two component to three component target triples for fuchsia.
Suggest `{var:?}` when finding `{?:var}` in inline format strings
Link to issue: https://github.com/rust-lang/rust/issues/106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
Enable Cargo's sparse protocol in CI
This enables the sparse protocol in CI in order to exercise and dogfood it. This is intended test the production server in a real-world situation.
Closes#107342
