Stabilize `const_exposed_provenance` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/144538) and stabilises `fn with_exposed_provenance` and `fn with_exposed_provenance_mut` in const
Do not copy files in `copy_src_dirs` in dry run
This reduces the time to run the current 9 dist snapshot tests from ~24s to ~2s on my PC.
r? `@jieyouxu`
Fix tracing debug representation of steps without arguments in bootstrap
I was wondering why I see `lainSourceTarbal` in tracing logs...
r? `@jieyouxu`
Remove duplicated tracing span in bootstrap
`trace_cmd` is now called also in the `stream` method, so including it also here was duplicating command spans.
r? `@jieyouxu`
fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`
missed this in rust-lang/rust#145275
since test calls `rustc` with `-C target-cpu mvp`
try-job: `test-various`
Implement `#[derive(From)]`
Implements the `#[derive(From)]` feature ([tracking issue](https://github.com/rust-lang/rust/issues/144889), [RFC](https://github.com/rust-lang/rfcs/pull/3809)).
It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
`apply_member_constraints`: fix placeholder check
Checking whether the member region is *an existential region from a higher universe* is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before rust-lang/rust#140466.
I've encountered this issue separately while working on rust-lang/rust#139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile
```rust
trait Proj<'a> {
type Assoc;
}
impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F {
type Assoc = ();
}
fn is_proj<F: for<'a> Proj<'a>>(f: F) {}
fn define<'a>() -> impl Sized + use<'a> {
// This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`.
// 'unconstrained_b is an inference variable from a higher universe as it gets
// created inside of the binder of `F: for<'a> Proj<'a>`. This previously
// caused us to not apply member constraints. We now do, constraining
// it to `'a`.
is_proj(define::<'a>);
&()
}
fn main() {}
```
This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc rust-lang/rust#140569/rust-lang/rust#142073. However, as we always skipped these member regions in `apply_member_constraints` the skipped region is guaranteed to cause an error in `check_member_constraints` later on.
Autolabel `src/tools/{rustfmt,rust-analyzer}` changes with `T-{rustfmt,rust-analyzer}`
Make e.g. rust-lang/rust#144323 more obvious who should be reviewing it and easier to filter.
Enhance UI test output handling for runtime errors
When a UI test runs a compiled binary and an error/forbid pattern check fails, the failure message previously only showed compiler output, hiding the executed programs stdout/stderr. This makes it harder to see near-miss or unexpected runtime lines.
Fixedrust-lang/rust#141531
Supersedes rust-lang/rust#141977
Fix wrong spans with external macros in the `dropping_copy_types` lint
This PR fixes some wrong spans manipulations when external macros are involved.
Specifically we didn't make sure the spans had the same context, which kind-of make our spans manipulations go wrong and produce weird spans. We fix that by making sure they have the same context.
Fixes https://github.com/rust-lang/rust/issues/145427
Fix typos in bootstrap.example.toml
Founds these small typos while looking around.
`equivelent` -> `equivalent`
`recommeded` -> `recommended`
cheers :)
bootstrap: Reduce dependencies
Eliminate the `fd-lock` dependency by using the new native locking in std.
Eliminate the `xattr` dependency by turning off a feature flag in `tar`, since
the tarballs that we extract with bootstrap don't need it.
Deduplicate -L search paths
For each -L passed to the compiler, we eagerly scan the whole directory. If it has a lot of files, that results in a lot of allocations. So it's needless to do this if some -L paths are actually duplicated (which can happen e.g. in the situation in the linked issue).
This PR both deduplicates the args, and also teaches rustdoc not to pass duplicated args to merged doctests.
Fixes: https://github.com/rust-lang/rust/issues/145375
Split codegen backend check step into two and don't run it with `x check compiler`
This reduces the amount of work that is done during `x check compiler`. We still check both backends during `x check` by defaut, even if they are not in `rust.codegen-backends`, as just checking them shouldn't require expensive preparations, like building GCC.
r? `@jieyouxu`
Reduce usage of `compiler_for` in bootstrap
While working on refactoring/fixing `dist` steps, I realized that `build.full-bootstrap` does much more than it should, and that it its documentation is wrong. It seems that the main purpose of this option should be to enable/disable stdlib/compiler uplifting (https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Purpose.20of.20.60build.2Efull-bootstrap.60/with/533985624), but currently it also affects staging, or more precisely which compiler will be used to build selected steps, because this option is used in the cursed `compiler_for` function.
I would like to change the option it so that it *only* affects uplifting, and doesn't affect stage selection, which I (partially) did in this PR. I removed the usage of `compiler_for` from the `Std` and `Rustc` steps, and explicitly implemented uplifting, without going through `compiler_for`.
The only remaining usages of `compiler_for` are in dist steps (which I'm currently refactoring, will send a PR later) and test steps (which I will take a look at after dist). After that we can finally remove the function.
I tried to document the case when uplifting was happening during cross-compilation, which was very implicit before. I also did a slight change in the uplifting logic for rustc when cross-compiling. Before, we would attempt to uplift a stage1 rustc, but that is not really a thing when cross-compiling.
r? `@jieyouxu`
std: thread: Return error if setting thread stack size fails
Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds.
This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully.
There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed.
[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
ignore head usages from ignored candidates
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns.
The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result.
We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability.
It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
When a UI test runs a compiled binary and an error/forbid pattern
check fails, the failure message previously only showed compiler output,
hiding the executed programs stdout/stderr. This makes it harder to
see near-miss or unexpected runtime lines.
coverage: Remove intermediate data structures from mapping creation
The data structures in `coverage::mappings` were historically very useful for isolating the details of mapping-extraction from the details of how coverage mappings are stored in MIR.
But because of various changes that have taken place over time, they now provide little value, and cause difficulty for the coordinated changes that will be needed for introducing expansion mapping support.
In the future, the pendulum might eventually swing back towards these being useful again, but we can always reintroduce suitable intermediate data structures if and when that happens. For now, the simplicity of not having this intermediate layer is a higher priority.
There should be no changes to compiler output.
Jana Dönszelmann