-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 5 pull requests #98025
Rollup of 5 pull requests #98025
Conversation
Repro: #![feature(backtrace)] use std::backtrace::Backtrace; use std::io::{self, Write as _}; use std::panic::{self, PanicInfo}; #[derive(Debug)] pub struct Error; fn panic_hook(panic_info: &PanicInfo) { let backtrace = Backtrace::force_capture(); let _ = write!(io::stdout(), "{}\n{}", panic_info, backtrace); } fn main() -> Result<(), Error> { panic::set_hook(Box::new(panic_hook)); let stderr = io::stderr(); let mut stderr = stderr.lock(); while stderr.write_all(b".\n").is_ok() {} Err(Error) } Before: $ RUST_BACKTRACE=1 target/debug/testing 3>&2 2>&1 1>&3 | head . . . . . . . . . . panicked at 'failed printing to stderr: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9 0: testing::panic_hook at ./src/main.rs:11:21 1: core::ops::function::Fn::call at /git/rust/library/core/src/ops/function.rs:77:5 2: std::panicking::rust_panic_with_hook 3: std::panicking::begin_panic_handler::{{closure}} 4: std::sys_common::backtrace::__rust_end_short_backtrace 5: rust_begin_unwind 6: core::panicking::panic_fmt 7: std::io::stdio::_eprint 8: <core::result::Result<!,E> as std::process::Termination>::report at /git/rust/library/std/src/process.rs:2164:9 9: <core::result::Result<(),E> as std::process::Termination>::report at /git/rust/library/std/src/process.rs:2148:25 10: std::rt::lang_start::{{closure}} at /git/rust/library/std/src/rt.rs:145:18 11: std::rt::lang_start_internal 12: std::rt::lang_start at /git/rust/library/std/src/rt.rs:144:17 13: main 14: __libc_start_main at /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 15: _start After: $ RUST_BACKTRACE=1 target/debug/testing 3>&2 2>&1 1>&3 | head . . . . . . . . . .
…=Dylan-DPC additional docs example for replace **all** of str
Fix Termination impl panic on closed stderr Repro: ```rust #![feature(backtrace)] use std::backtrace::Backtrace; use std::io::{self, Write as _}; use std::panic::{self, PanicInfo}; #[derive(Debug)] pub struct Error; fn panic_hook(panic_info: &PanicInfo) { let backtrace = Backtrace::force_capture(); let _ = write!(io::stdout(), "{}\n{}", panic_info, backtrace); } fn main() -> Result<(), Error> { panic::set_hook(Box::new(panic_hook)); let stderr = io::stderr(); let mut stderr = stderr.lock(); while stderr.write_all(b".\n").is_ok() {} Err(Error) } ``` ### Before: ```console $ target/debug/repro 3>&2 2>&1 1>&3 | head . . . . . . . . . . panicked at 'failed printing to stderr: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9 0: testing::panic_hook at ./src/main.rs:11:21 1: core::ops::function::Fn::call at /git/rust/library/core/src/ops/function.rs:77:5 2: std::panicking::rust_panic_with_hook 3: std::panicking::begin_panic_handler::{{closure}} 4: std::sys_common::backtrace::__rust_end_short_backtrace 5: rust_begin_unwind 6: core::panicking::panic_fmt 7: std::io::stdio::_eprint 8: <core::result::Result<!,E> as std::process::Termination>::report at /git/rust/library/std/src/process.rs:2164:9 9: <core::result::Result<(),E> as std::process::Termination>::report at /git/rust/library/std/src/process.rs:2148:25 10: std::rt::lang_start::{{closure}} at /git/rust/library/std/src/rt.rs:145:18 11: std::rt::lang_start_internal 12: std::rt::lang_start at /git/rust/library/std/src/rt.rs:144:17 13: main 14: __libc_start_main at /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 15: _start ``` ### After: ```console $ target/debug/repro 3>&2 2>&1 1>&3 | head . . . . . . . . . . ```
…plett Use safer `strip=symbols`-flag for dylibs on macOS Closes rust-lang#93988 To safely strip dylibs on macOS, the `-x` flag is needed per the manpage (see the discussion here: rust-lang#93988 (comment)). Thus, when the current `crate_type` is producing a dylib (I assume this is the case for proc macros) use the `-x` flag instead of bare `strip` for `strip=symbols`.
…=joshtriplett Stabilize scoped threads. Tracking issue: rust-lang#93203 FCP finished here: rust-lang#93203 (comment)
…-traits, r=cjgillot `ValuePairs::PolyTraitRefs` should be called "trait"s in type error diagnostics Pretty simple, we already do this for `ValuePairs::TraitRefs`...
@bors r+ rollup=never p=5 |
📌 Commit 53090fe has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (53305f1): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
All six regressions are variations of issue-88862 (#88862): {opt,debug} x { incr-full, full, incr-unchanged }. The two incr-unchanged cases regressed by 0.94% and 1.72% . The full cases regressed by 7.13% and 7.57% . The incr-full cases regressed by 7.86% and 7.80%. |
None of these PRs strike me as something that would cause a problem for the code exercised by #88862. (I briefly thought it might be #98012, but issue-88862 doesn't exercise HKT's...) but also, given that issue-88862 is a canary that is trying to catch a catastrophic regression, I think we can accept a 7-8% regression here. @rustbot label: +perf-regression-triaged |
Successful merges:
strip=symbols
-flag for dylibs on macOS #97991 (Use saferstrip=symbols
-flag for dylibs on macOS)ValuePairs::PolyTraitRefs
should be called "trait"s in type error diagnostics #98012 (ValuePairs::PolyTraitRefs
should be called "trait"s in type error diagnostics)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup