Fix Deref args when #[const_trait] is enabled by compiler-errors · Pull Request #118386 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation26 Commits2 Checks0 Files changed
Conversation
This file contains hidden or 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
[ Show hidden characters]({{ revealButtonHref }})
Fix Deref being a #[const_trait]. To fix this fully, we also need to pass the host param to method_autoderef_steps and make sure we use it correctly in Autoderef.
Status: This is awaiting some action (such as code changes or more information) from the author.
label
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
This comment has been minimized.
This code is still broken for two reasons:
method_autoderef_stepsdoesn't know anything about the constness of the function, so it fails to select aDerefimpl cause of ambiguity- Projections have a host parameter but we don't currently know what to do with them...
This is ready :>
We just need to pass the host param to Autoderef and canonicalize it in method_autoderef_steps.
@bors try @rust-timer queue
This comment has been minimized.
bors added a commit to rust-lang-ci/rust that referenced this pull request
Fix Deref args when #[const_trait] is enabled
r? @fee1-dead
This is still pretty broken, but putting this PR up so I don't lose the code in some git stash somewhere...
☀️ Try build successful - checks-actions
Build commit: 4a90a2c (4a90a2c83dbb51ae7aa0f7efa5b3aba7cd165e4f)
This comment has been minimized.
Finished benchmarking commit (4a90a2c): comparison URL.
Overall result: ❌ regressions - ACTION NEEDED
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.
Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.
@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.4% | [0.1%, 0.7%] | 38 |
| Regressions ❌ (secondary) | 0.5% | [0.2%, 0.8%] | 8 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 0.4% | [0.1%, 0.7%] | 38 |
Max RSS (memory usage)
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | 0.8% | [0.8%, 0.8%] | 1 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -2.7% | [-2.7%, -2.7%] | 1 |
| All ❌✅ (primary) | - | - | 0 |
Cycles
This benchmark run did not return any relevant results for this metric.
Binary size
This benchmark run did not return any relevant results for this metric.
Bootstrap: 673.958s -> 673.623s (-0.05%)
Artifact size: 312.41 MiB -> 312.44 MiB (0.01%)
I feel like we just need to accept this perf regression 😅, since it's likely not possible to avoid needing to pass in the host param in method_autoderef_steps, and we're simply doing more work here. Happy to discuss this if anyone disagrees, though.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry about the lack of response here, r=me after the two tiny nits
This comment has been minimized.
bors added a commit to rust-lang-ci/rust that referenced this pull request
Fix Deref args when #[const_trait] is enabled
Fix Deref being a #[const_trait]. To fix this fully, we also need to pass the host param to method_autoderef_steps and make sure we use it correctly in Autoderef.
☀️ Try build successful - checks-actions
Build commit: 34aeaa2 (34aeaa28971ceecb8ae34abcf0c3d6ab41e0a673)
This comment has been minimized.
Finished benchmarking commit (34aeaa2): comparison URL.
Overall result: ❌ regressions - ACTION NEEDED
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.
Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.
@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.4% | [0.2%, 0.7%] | 40 |
| Regressions ❌ (secondary) | 0.4% | [0.2%, 0.8%] | 11 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 0.4% | [0.2%, 0.7%] | 40 |
Max RSS (memory usage)
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.9% | [0.9%, 0.9%] | 1 |
| Regressions ❌ (secondary) | 10.5% | [10.5%, 10.5%] | 1 |
| Improvements ✅ (primary) | -0.8% | [-1.1%, -0.5%] | 2 |
| Improvements ✅ (secondary) | -1.9% | [-2.5%, -1.3%] | 3 |
| All ❌✅ (primary) | -0.2% | [-1.1%, 0.9%] | 3 |
Cycles
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | 2.0% | [2.0%, 2.0%] | 1 |
| Improvements ✅ (primary) | -0.6% | [-0.8%, -0.5%] | 2 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | -0.6% | [-0.8%, -0.5%] | 2 |
Binary size
This benchmark run did not return any relevant results for this metric.
Bootstrap: 667.831s -> 668.134s (0.05%)
Artifact size: 308.39 MiB -> 308.55 MiB (0.05%)
I think there may be potential optimizations related to caching behavior with the host generic params. Currently the trait system would probably cache non-const trait bounds and const trait bounds separately. If we find a way to mark which host args come from the original obligation carried forward, then we'd only need to select traits once (considering that concrete impls like impl const always implements both non-const and const, giving us a happy path).
I'm not entirely sure why we'd have this many regressions, though. expected_host_effect_param_for_body is only different if we are in a const fn, where there shouldn't be any deref (though we'd still have to check when typechecking method calls?) We might try to fix the regressions on stable code by checking the effects feature somewhere, and just passing in tcx.consts.true_ if we don't have effects enabled.
Well, hmm, it looks like expected_host_effect_param_for_body already forces the host the param to be true. Why would this have a regression then?
I think it may just be due to additional caching. I will test a few things, but otherwise I feel like we should absorb the perf hit since it seems inevitable.
feel free to r=me after you have done the testing
This is gonna have to be reworked after @fee1-dead adjusts the const trait desugaring, I think. Or otherwise, this can be revived later.
Labels
Performance regression.
Status: This is awaiting some action (such as code changes or more information) from the author.
Relevant to the compiler team, which will review and decide on the PR/issue.