-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 4 pull requests #95448
Rollup of 4 pull requests #95448
Conversation
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
…ebration-station, r=joshtriplett Stabilize Termination and ExitCode From rust-lang#43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name, as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone, Copy, Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From<u8> for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API, letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From<u8> for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers, as needed.
Ensure io::Error's bitpacked repr doesn't accidentally impl UnwindSafe Sadly, I'm not sure how to easily test that we don't impl a trait, though (or can libstd use `where io::Error: !UnwindSafe` or something). Fixes rust-lang#95203
…-obk Suggest wrapping patterns in enum variants Structured suggestion to wrap a pattern in a single-field enum or struct: ```diff struct A; enum B { A(A), } fn main(b: B) { match b { - A => {} + B::A(A) => {} } } ``` Half of rust-lang#94942, the other half I'm not exactly sure how to fix. Also includes two drive-by changes (that I am open to splitting out into another PR, but thought they could be rolled up into this one): - 07776c1: Makes sure not to suggest wrapping if it doesn't have tuple field constructor (i.e. has named fields) - 8f2bbb18fd53e5008bb488302dbd354577698ede: Also suggest wrapping expressions in a tuple struct (not just enum variants)
…compiler-errors diagnostics: regression test for derive bounds Closes rust-lang#79076
@bors r+ rollup=never p=5 |
📌 Commit 2471502 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9c06e1b): comparison url. Summary: This benchmark run shows 5 relevant regressions 😿 to instruction counts.
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 |
Visiting for weekly performance triage. The only primary benchmark impacted by this was The only secondary benchmark that was impacted was issue-46449, which saw a 2% to 2.5% regression on three scenarios. Looking over the four PR's in this rollup, I do not think its worth trying to tease out the cause of the regression to that secondary benchmark. Specifically, issue-46449 is tied to #46449 ; the problem it is trying to catch was tied to quadratic slowdown, not a minor change of a few percentage points. @rustbot label: +perf-regression-triaged |
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup