-
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
Improve some deriving code and add a test #98376
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 6dbf740b2dc586a3390b3b15ff6c1d2a8e514544 with merge 85aa84416c76589d4348da14583233ee4de50e8d... |
☀️ Try build successful - checks-actions |
Queued 85aa84416c76589d4348da14583233ee4de50e8d with parent 3d829a0, future comparison URL. |
Finished benchmarking commit (85aa84416c76589d4348da14583233ee4de50e8d): 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. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
I wonder how would perf. look like without the last commit? Without the |
I haven't measured but I'm confident that the last commit is responsible for 99% the perf wins. The first commit is the only other one that affects the generated code, and it just removes one I liked @jyn514's comment on Zulip, about the possibility of behavioural changes with this PR if you derive |
6dbf740
to
fb58eff
Compare
@bors r+ |
📌 Commit fb58effead00fd320ddf6be51ebbf4779f4e9e9d has been approved by |
🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened. |
Currently the generated code for methods like `eq`, `ne`, and `partial_cmp` includes stuff like this: ``` let __self_vi = ::core::intrinsics::discriminant_value(&*self); let __arg_1_vi = ::core::intrinsics::discriminant_value(&*other); if true && __self_vi == __arg_1_vi { ... } ``` This commit removes the unnecessary `true &&`, and makes the generating code a little easier to read in the process. It also fixes some errors in comments.
Because the latter just calls the former. The commit also updates some details in a comment.
I think a remnant of Do the |
They do, both via The problem appears to be this:
I don't understand these coverage tests at all, so I'm not sure if just updating the expected output to remove those lines is reasonable... |
Oh, it seems the |
Neither do I, but at least seeing an "unexecuted instantiation of And that seemed to match the idea that it was a safe function to delete indeed. |
I think this PR should have a T-libs-api FCP on it, since it does modify stable behavior. It's likely okay to change that behavior - we document that eq and ne should match - but I could see this breaking users if they're writing custom impls and so I think it merits additional consideration. At minimum, marking relnotes and will edit the description with a short note for why. |
I'm going to remove the last commit from this PR, which is the one that removes the I will then file a new PR just for the |
4e5ceba
to
02d2cdf
Compare
derive(PartialEq)
I removed the final commit. I'll file the new PR for the @bors r=petrochenkov |
📌 Commit 02d2cdf has been approved by |
☀️ Test successful - checks-actions |
That is #98655. |
Finished benchmarking commit (126e3df): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
The
.stdout
test is particularly useful.r? @petrochenkov