rustup #2903
Merged
rustup #2903
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
Improve startup time of bootstrap ~~If the user has a `build/host` symlink set up, we can determine the target triple by reading it rather than invoking rustc. This significantly reduces startup time of bootstrap once any kind of build has been done~~ New approach explained below ``` ➜ hyperfine -p 'git checkout -q master' -N './x.py -h' -r 50 Benchmark 1: ./x.py -h Time (mean ± σ): 140.7 ms ± 2.6 ms [User: 99.9 ms, System: 39.3 ms] Range (min … max): 136.8 ms … 149.6 ms 50 runs ➜ rust git:(master) hyperfine -p 'git checkout -q speedup-bootstrap-py' -N './x.py -h' -r 50 Benchmark 1: ./x.py -h Time (mean ± σ): 95.2 ms ± 1.5 ms [User: 67.7 ms, System: 26.7 ms] Range (min … max): 92.9 ms … 99.6 ms 50 runs ``` Also a small microoptimisation in using string splitting rather than regex when reading toml, which saves a few more milliseconds (2-5 testing locally), but less important. Profiling shows the remaining runtime is around half setting up the Python runtime, and the vast majority of the remaining time is spent in subprocess building and running bootstrap itself, so probably can't be improved much further.
…lnay Remove structural match from `TypeId` As per rust-lang/rust#99189 (comment). > Removing the structural equality might make sense, but is a breaking change that'd require a libs-api FCP. rust-lang/rust#99189 (comment) > Landing this PR now (well, mainly the "remove structural equality" part) would unblock `const fn` `TypeId::of`, since we only postponed that because we were guaranteeing too much. See also #99189, #101698
…lbertlarsan68,oli-obk new tool `rustdoc-gui-test` Implements new tool `rustdoc-gui-test` that allows using compiletest headers for `rustdoc-gui` tests.
[RFC-2011] Expand more expressions
cc #44838
Expands `if`, `let`, `match` and also makes `generic_assert_internals` an allowed feature when using `assert!`. `#![feature(generic_assert)]` is still needed to activate everything.
```rust
#![feature(generic_assert)]
fn fun(a: Option<i32>, b: Option<i32>, c: Option<i32>) {
assert!(
if a.is_some() { 1 } else { 2 } == 3
&& if let Some(elem) = b { elem == 4 } else { false }
&& match c { Some(_) => true, None => false }
);
}
fn main() {
fun(Some(1), None, Some(2));
}
// Assertion failed: assert!(
// if a.is_some() { 1 } else { 2 } == 3
// && if let Some(elem) = b { elem == 4 } else { false }
// && match c { Some(_) => true, None => false }
// );
//
// With captures:
// a = Some(1)
// b = None
// c = Some(2)
```
Stabilize `BuildHasher::hash_one` FCP completed in rust-lang/rust#86161 (comment)
Rework handling of recursive panics
This PR makes 2 changes to how recursive panics works (a panic while handling a panic).
1. The panic count is no longer used to determine whether to force an immediate abort. This allows code like the following to work without aborting the process immediately:
```rust
struct Double;
impl Drop for Double {
fn drop(&mut self) {
// 2 panics are active at once, but this is fine since it is caught.
std::panic::catch_unwind(|| panic!("twice"));
}
}
let _d = Double;
panic!("once");
```
Rustc already generates appropriate code so that any exceptions escaping out of a `Drop` called in the unwind path will immediately abort the process.
2. Any panics while the panic hook is executing will force an immediate abort. This is necessary to avoid potential deadlocks like #110771 where a panic happens while holding the backtrace lock. We don't even try to print the panic message in this case since the panic may have been caused by `Display` impls.
Fixes #110771
1.70.0 release notes r? `@cuviper` `@rust-lang/release`
…chenkov Add warn-by-default lint when local binding shadows exported glob re-export item This PR introduces a warn-by-default rustc lint for when a local binding (a use statement, or a type declaration) produces a name which shadows an exported glob re-export item, causing the name from the exported glob re-export to be hidden (see #111336). ### Unresolved Questions - [x] ~~Is this approach correct? While it passes the UI tests, I'm not entirely convinced it is correct.~~ Seems to be ok now. - [x] ~~What should the lint be called / how should it be worded? I don't like calling `use x::*;` or `struct Foo;` a "local binding" but they are `NameBinding`s internally if I'm not mistaken.~~ ~~The lint is called `local_binding_shadows_glob_reexport` for now, unless a better name is suggested.~~ `hidden_glob_reexports`. Fixes #111336.
Add support for LLVM SafeStack Adds support for LLVM [SafeStack] which provides backward edge control flow protection by separating the stack into two parts: data which is only accessed in provable safe ways is allocated on the normal stack (the "safe stack") and all other data is placed in a separate allocation (the "unsafe stack"). SafeStack support is enabled by passing `-Zsanitizer=safestack`. [SafeStack]: https://clang.llvm.org/docs/SafeStack.html cc `@rcvalle` #39699
…cjgillot Enable MatchBranchSimplification This pass is one of the small number of benefits from `-Zmir-opt-level=3` that has motivated rustc_codegen_cranelift to use it: https://github.com/rust-lang/rust/blob/19ed0aade60e1c1038fe40554bcd9d01b717effa/compiler/rustc_codegen_cranelift/build_system/build_sysroot.rs#L244-L246 Cranelift's motivation for this is _runtime_ performance improvements in debug builds. Lifting this pass all the way to `-Zmir-opt-level=1` seems to come without significant perf overhead, so that's what I'm suggesting here.
Don't check for misaligned raw pointer derefs inside Rvalue::AddressOf From rust-lang/rust#112026 (comment): rustc 1.70 (stable next week) added a Mir pass to add pointer alignment checks in debug mode. Adding these checks caused some crates to break, but that was expected, since they contain broken code (rust-lang/rust#111487) for tracking that. However, the checks added are slightly more aggressive than they should have been. Specifically, they also check the place in an `addr_of!` expression. Whether lack of alignment there is or isn't UB is unclear. This PR modifies the pass to not affect those cases. I spot checked the crater regressions and the ones I saw were not the case that this PR is modifying. It still seems good to not land anything overaggressive though
MIR: opt-in normalization of `BasicBlock` and `Local` numbering This doesn't matter at all for actual codegen, but after spending some time reading pre-codegen MIR, I was wishing I didn't have to jump around so much in reading post-inlining code. So this add two passes that are off by default for every mir level, but can be enabled (`-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals`) for humans.
|
@bors r+ |
|
@bors r+ (Feel free to self-approve these) |
|
💡 This pull request was already approved, no need to approve it again. |
|
Oh wait you did. Bors is just broken again (Cc rust-lang/homu#191). |
|
☀️ Test successful - checks-actions |
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.
No description provided.