Rollup of 11 pull requests #73422
Closed
Rollup of 11 pull requests #73422
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When parsing `let x: i8 += 1` the compiler interprets `i8` as a trait which makes it more complicated to do error recovery. More advanced error recovery is not implemented in this commit.
This should run much faster. There are also some drive-by cleanups here to try to simplify things. Also, the paths for in-tree crates are now displayed as relative in `x.py test -h -v`.
This commit intends to fix an accidental regression from rust-lang#70846. The goal of rust-lang#70846 was to build compiler-builtins with a maximal number of CGUs to ensure that each module in the source corresponds to an object file. This high degree of control for compiler-builtins is desirable to ensure that there's at most one exported symbol per CGU, ideally enabling compiler-builtins to not conflict with the system libgcc as often. In rust-lang#70846, however, only part of the compiler understands that compiler-builtins is built with many CGUs. The rest of the compiler thinks it's building with `sess.codegen_units()`. Notably the calculation of `sess.lto()` consults `sess.codegen_units()`, which when there's only one CGU it disables ThinLTO. This means that compiler-builtins is built without ThinLTO, which is quite harmful to performance! This is the root of the cause from rust-lang#73135 where intrinsics were found to not be inlining trivial functions. The fix applied in this commit is to remove the special-casing of compiler-builtins in the compiler. Instead the build system is now responsible for special-casing compiler-builtins. It doesn't know exactly how many CGUs will be needed but it passes a large number that is assumed to be much greater than the number of source-level modules needed. After reading the various locations in the compiler source, this seemed like the best solution rather than adding more and more special casing in the compiler for compiler-builtins. Closes rust-lang#73135
Fix rust-lang#70968, partially address rust-lang#66523.
This mode is unnecessary because it's always ok to evaluate the right-hand side of assignments even if the left-hand side should not have reads propagated.
…komatsakis Expand "recursive opaque type" diagnostic Fix rust-lang#70968, partially address rust-lang#66523.
…ps, r=oli-obk [mir-opt] Small ConstProp cleanup
Improve diagnostics for `let x += 1` Fixes(?) rust-lang#66736 The code responsible for the `E0404` errors is [here](https://github.com/rust-lang/rust/blob/master/src/librustc_parse/parser/ty.rs#L399-L424) which I don't think can be easily modified to prevent emitting an error in one specific case. Because of this I couldn't get rid of `E0404` and instead added `E0067` along with a help message which will fix the problem. r? @estebank
…akis add raw_ref macros In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros. I'll create the tracking issue if we're okay moving forward with this.
…epmaster Add tests for 'impl Default for [T; N]' Related: rust-lang#71690. This pull request adds two tests: - Even it T::default() panics, no leaks occur. - [T; 0] is Default even if T is not. I believe at some moment `Default` impl for arrays will be rewritten to use const generics instead of macros, and these tests will help to prevent behavior changes.
…i-obk remove visit_terminator_kind from MIR visitor For some reason, we had both `visit_terminator` and `visit_terminator_kind`. In contrast, for `Statement` we just have `visit_statement`. So this cleans things up by removing `visit_terminator_kind` and porting its users to `visit_terminator`.
…ies, r=shepmaster Complete the std::time documentation to warn about the inconsistencies between OS Fix for rust-lang#48980. I put the new documentation in `src/libstd/time.rs` at the module-level because it affects all types, even the one that are not directly system dependents if they are used with affected types, but there may be a better place for it.
Fix link error with #[thread_local] introduced by rust-lang#71192 r? @oli-obk
…ins, r=Mark-Simulacrum Change how compiler-builtins gets many CGUs This commit intends to fix an accidental regression from rust-lang#70846. The goal of rust-lang#70846 was to build compiler-builtins with a maximal number of CGUs to ensure that each module in the source corresponds to an object file. This high degree of control for compiler-builtins is desirable to ensure that there's at most one exported symbol per CGU, ideally enabling compiler-builtins to not conflict with the system libgcc as often. In rust-lang#70846, however, only part of the compiler understands that compiler-builtins is built with many CGUs. The rest of the compiler thinks it's building with `sess.codegen_units()`. Notably the calculation of `sess.lto()` consults `sess.codegen_units()`, which when there's only one CGU it disables ThinLTO. This means that compiler-builtins is built without ThinLTO, which is quite harmful to performance! This is the root of the cause from rust-lang#73135 where intrinsics were found to not be inlining trivial functions. The fix applied in this commit is to remove the special-casing of compiler-builtins in the compiler. Instead the build system is now responsible for special-casing compiler-builtins. It doesn't know exactly how many CGUs will be needed but it passes a large number that is assumed to be much greater than the number of source-level modules needed. After reading the various locations in the compiler source, this seemed like the best solution rather than adding more and more special casing in the compiler for compiler-builtins. Closes rust-lang#73135
…, r=kinnison Clean up some weird command strings r? @kinnison
…mulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation, and this attempts to avoid the extra calls. On my system, a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there, it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim`, I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run`, these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates`, etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.
|
@bors r+ p=2 |
|
📌 Commit eb5d3eb has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit eb5d3eb with merge d9808911761a891ea010559c77cc856817444b1a... |
|
💥 Test timed out |
bors
added
S-waiting-on-review
|
superseded by #73438 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
let x += 1#71976 (Improve diagnostics forlet x += 1)Failed merges:
r? @ghost