-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #128435
Rollup of 9 pull requests #128435
Conversation
Currently the output on failure is as follows: Compiling block-buffer v0.10.4 Compiling crypto-common v0.1.6 Compiling digest v0.10.7 Compiling sha2 v0.10.8 Compiling xz2 v0.1.7 error: failed to build archive: No such file or directory error: could not compile `bootstrap` (lib) due to 1 previous error Print which file is being constructed to give some hint about what is going on.
…d in import When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```
remove an unused boolean and then merge two big matches into one
When it used `HashMap`, `bump-stage0` would change `src/stage0` every time it ran, whereas `IndexMap` will keep insertion order -- matching the manifest file.
This further reduces the amount of code that relies on `thir::Pat` being printable.
This reverts commit ae0ec73. The original change in rust-lang#128304 was intended to be a step towards being able to print `thir::Pat` even after switching to `PatId`. But because the only patterns that need to be printed are the synthetic ones created by pattern analysis (for diagnostic purposes only), it makes more sense to completely separate the printable patterns from the real THIR patterns.
The pattern-analysis code needs to print patterns, as part of its user-visible diagnostics. But it never actually tries to print "real" patterns! Instead, it only ever prints synthetic patterns that it has reconstructed from its own internal represenations. We can therefore simultaneously remove two obstacles to changing `thir::Pat`, by having the pattern-analysis code use its own dedicated type for building printable patterns, and then making `thir::Pat` not printable at all.
bump-stage0: use IndexMap for determinism When it used `HashMap`, `bump-stage0` would change `src/stage0` every time it ran, whereas `IndexMap` will keep insertion order -- matching the manifest file. I included an actual bump here mainly to reset the order, but that did update to a new rustfmt nightly too.
… r=compiler-errors derive(SmartPointer): rewrite bounds in where and generic bounds Fix rust-lang#127647 Due to the `Unsize` bounds, we need to commute the bounds on the pointee type to the new self type. cc ```@Darksonn```
…r=BoxyUwU When an archive fails to build, print the path Currently the output on failure is as follows: Compiling block-buffer v0.10.4 Compiling crypto-common v0.1.6 Compiling digest v0.10.7 Compiling sha2 v0.10.8 Compiling xz2 v0.1.7 error: failed to build archive: No such file or directory error: could not compile `bootstrap` (lib) due to 1 previous error Change this to print which file is being constructed, to give some hint about what is going on. error: failed to build archive at `path/to/output`: No such file or directory
…etrochenkov Structured suggestion for `extern crate foo` when `foo` isn't resolved in import When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```
More detailed note to deprecate ONCE_INIT
…-windows-abi, r=tgross35 Match LLVM ABI in `extern "C"` functions for `f128` on Windows As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work. I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`. Tracking issue: rust-lang#116909 try-job: x86_64-msvc try-job: x86_64-mingw
…errors Attribute checking simplifications remove an unused boolean and then merge two big matches into one I was reviewing some attributes and realized we don't really check this list against the list of builtin attributes, so we "may" totally be missing some attributes that we should be checking (like the `coroutine` attribute, which you can just apply to random stuff) ```rust #![feature(coroutines)] #[coroutine] struct Foo; ``` just compiles for example. Unless we check that the fallthrough match arm is never reached for builtin attributes, we're just going to keep forgetting to add them here, too. I can do that without the changes in this PR, but it seemed like a nice cleanup
…r=cjgillot Remove `crate_level_only` from `ELIDED_LIFETIMES_IN_PATHS` As far as I can tell, we provide the right node id to the `ELIDED_LIFETIMES_IN_PATHS` lint: https://github.com/rust-lang/rust/blob/f8060d282d42770fadd73905e3eefb85660d3278/compiler/rustc_resolve/src/late.rs#L2015-L2027 So I've gone ahead and removed the restriction from this lint.
Use a separate pattern type for `rustc_pattern_analysis` diagnostics The pattern-analysis code needs to print patterns, as part of its user-visible diagnostics. But it never actually tries to print "real" patterns! Instead, it only ever prints synthetic patterns that it has reconstructed from its own internal represenations. We can therefore simultaneously remove two obstacles to changing `thir::Pat`, by having the pattern-analysis code use its own dedicated type for building printable patterns, and then making `thir::Pat` not printable at all. r? `@Nadrieril`
@bors r+ rollup=never p=9 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 0b5eb7ba7b In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (99322d8): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 755.634s -> 755.782s (0.02%) |
Successful merges:
extern crate foo
whenfoo
isn't resolved in import #128151 (Structured suggestion forextern crate foo
whenfoo
isn't resolved in import)extern "C"
functions forf128
on Windows #128388 (Match LLVM ABI inextern "C"
functions forf128
on Windows)crate_level_only
fromELIDED_LIFETIMES_IN_PATHS
#128412 (Removecrate_level_only
fromELIDED_LIFETIMES_IN_PATHS
)rustc_pattern_analysis
diagnostics #128430 (Use a separate pattern type forrustc_pattern_analysis
diagnostics )r? @ghost
@rustbot modify labels: rollup
Create a similar rollup