-
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
stabilize int_error_matching
#84910
stabilize int_error_matching
#84910
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Posted one comment about not stabilizing |
r? @joshtriplett for the T-libs FCP and since you've already started a review here |
@rfcbot merge |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
☔ The latest upstream changes (presumably #85014) made this pull request unmergeable. Please resolve the merge conflicts. |
1fa0d8b
to
7b6573c
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #85058) made this pull request unmergeable. Please resolve the merge conflicts. |
You're going to hate me, but I got a snag. https://godbolt.org/z/fPx6ThTYx I would love to understand what's going on because the error is clearly smaller than a u128 even with a fair few enum varients. I don't know why llvm would generate different assembly. I take it mov is much slower than an xor but why llvm why? |
(I know worrying about 3ms when the largest i128 currently takes 300ns to parse seems pedantic but I'm working on getting parsing 128s to below 20ns worstcase so it's becoming not insignificant.) |
Hmm, seems like our side looking at the generated llvm instructions, but I'm not great at reading the runes. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
☔ The latest upstream changes (presumably #84985) made this pull request unmergeable. Please resolve the merge conflicts. |
7eb3b38
to
62e6b8f
Compare
☔ The latest upstream changes (presumably #86204) made this pull request unmergeable. Please resolve the merge conflicts. |
62e6b8f
to
85b06e9
Compare
This should be ready for merge. @joshtriplett Do you need to do something to merge this? |
I think we only need to update the version field in the |
@bors r=yaahc |
📌 Commit 52a6885 has been approved by |
☀️ Test successful - checks-actions |
@XAMPPRocky This seems to have been missed in relnotes? |
@pthariensflame Thanks for the catch! Would you be able to open up a PR or issue for this and the couple of others you caught? I can't get to it immediately, and I want to make sure it doesn't get lost. |
Will do, later today! |
closes #22639
Originally posted by @kennytm in #22639 (comment)