-
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
Arbitrary self types v2: probe for more methods, take two #128548
Arbitrary self types v2: probe for more methods, take two #128548
Conversation
|
r? @wesleywiser though it's still a draft PR and not quite ready for review yet. In any case the purpose is performance testing, I'm not saying this is mergable quality. |
This comment has been minimized.
This comment has been minimized.
8649ead
to
6e830c3
Compare
This comment has been minimized.
This comment has been minimized.
6e830c3
to
ac957e3
Compare
Rust prioritizes method candidates in this order: 1. By value; 2. By reference; 3. By mutable reference; 4. By const ptr. Previously, if a suitable candidate was found in one of these earlier categories, Rust wouldn't even move onto probing the other categories. As part of the arbitrary self types work, we're going to need to change that - even if we choose a method from one of the earlier categories, we will sometimes need to probe later categories to search for methods that we may be shadowing. This commit adds those extra searches for shadowing, but it does not yet produce an error when such shadowing problems are found. That will come in a subsequent commit, by filling out the 'check_for_shadowing' method. We're adding the extra searches in a preliminary commit because they are the risky bit. We want to find any functional or performance problems from these extra searches before we proceed with the actual work on arbitrary self types and specifically on extra deshadowing errors.
A subsequent commit will involve working out which methods actually shadow other methods, and one of the rules will be to compare the depth via a chain of Receiver traits of the shadowing and shaodwed methods. This commit records this information; currently unused.
This commit applies constraints to the searches we perform when searching for potential shadows, in order to make that search quicker.
ac957e3
to
7f90c11
Compare
I don't know if I have permission to do this, let's see: @rust-timer build 7f90c11 |
This comment has been minimized.
This comment has been minimized.
Well, my dear bot, that's what I thought you'd say :) In that case @wesleywiser I am marking this as "ready for review" but as noted, it's not really mergable-quality yet, it's more to do a performance test to determine if this approach to deshadowing is feasible without significant performance penalty (if so, I will clean things up before merging). So if you wouldn't mind redoing this that'd be much appreciated. |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…_deshadowing_probes_v2, r=<try> Arbitrary self types v2: probe for more methods, take two This is a new version of rust-lang#127812. Here's what I said last time, which still applies: This PR is one of the first steps towards arbitrary self types v2, RFC [3519](rust-lang/rfcs#3519) (rust-lang#44874). Specifically, it is [step 2 of the plan outlined here](rust-lang#44874 (comment)). That says: > 1. **Search for potentially conflicting method candidates** per the [deshadowing part of the RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md#compiler-changes-deshadowing). This is the riskiest part - per > the production of errors requires us to interrogate more candidates to look for potential conflicts, so this could have a compile-time performance penalty which we should measure > let's attempt to land this first and see if performance issues show up. If so, it's back to the drawing board. So - this commit isn't useful in itself but we need to determine its performance and any unexpected compatibility problems. That's what this PR is for. We shouldn't necessarily merge it. Here's what this PR does. Rust prioritizes method candidates in this order: 1. By value; 2. By reference; 3. By mutable reference; 4. By const ptr. Previously, if a suitable candidate was found in one of these earlier categories, Rust wouldn't even move onto probing the other categories. As part of the arbitrary self types work, we're going to need to change that - even if we choose a method from one of the earlier categories, we will sometimes need to probe later categories to search for methods that we may be shadowing. This commit adds those extra searches for shadowing, but it does not yet produce an error when such shadowing problems are found. That will come in a subsequent commit, by filling out the 'check_for_shadowing' method. We're adding the extra searches in a preliminary commit because they are the risky bit. We want to find any functional or performance problems from these extra searches before we proceed with the actual work on arbitrary self types and specifically on extra deshadowing errors. -- What's different this time relative to rust-lang#127812? Well, this is a more invasive change to the probing algorithm which hopefully minimizes the amount of work done during the extra probing for shadowed methods. Specifically, we only need to warn about potentially shadowed methods if three conditions are true: * the shadowed method is not the same as the shadower (different `DefId`s) * the potential shadower involves the same `self` type as the shadowed method * the potential shadower has been found at a different position along the chain of `Receiver` traits than the shadowed. Previously, we checked these conditions only when a potentially shadowed pick was found. We now apply them during the search process, which should minimize the amount of work required.
…_deshadowing_probes_v2, r=<try> Arbitrary self types v2: probe for more methods, take two This is a new version of rust-lang#127812. Here's what I said last time, which still applies: This PR is one of the first steps towards arbitrary self types v2, RFC [3519](rust-lang/rfcs#3519) (rust-lang#44874). Specifically, it is [step 2 of the plan outlined here](rust-lang#44874 (comment)). That says: > 1. **Search for potentially conflicting method candidates** per the [deshadowing part of the RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md#compiler-changes-deshadowing). This is the riskiest part - per > the production of errors requires us to interrogate more candidates to look for potential conflicts, so this could have a compile-time performance penalty which we should measure > let's attempt to land this first and see if performance issues show up. If so, it's back to the drawing board. So - this commit isn't useful in itself but we need to determine its performance and any unexpected compatibility problems. That's what this PR is for. We shouldn't necessarily merge it. Here's what this PR does. Rust prioritizes method candidates in this order: 1. By value; 2. By reference; 3. By mutable reference; 4. By const ptr. Previously, if a suitable candidate was found in one of these earlier categories, Rust wouldn't even move onto probing the other categories. As part of the arbitrary self types work, we're going to need to change that - even if we choose a method from one of the earlier categories, we will sometimes need to probe later categories to search for methods that we may be shadowing. This commit adds those extra searches for shadowing, but it does not yet produce an error when such shadowing problems are found. That will come in a subsequent commit, by filling out the 'check_for_shadowing' method. We're adding the extra searches in a preliminary commit because they are the risky bit. We want to find any functional or performance problems from these extra searches before we proceed with the actual work on arbitrary self types and specifically on extra deshadowing errors. -- What's different this time relative to rust-lang#127812? Well, this is a more invasive change to the probing algorithm which hopefully minimizes the amount of work done during the extra probing for shadowed methods. Specifically, we only need to warn about potentially shadowed methods if three conditions are true: * the shadowed method is not the same as the shadower (different `DefId`s) * the potential shadower involves the same `self` type as the shadowed method * the potential shadower has been found at a different position along the chain of `Receiver` traits than the shadowed. Previously, we checked these conditions only when a potentially shadowed pick was found. We now apply them during the search process, which should minimize the amount of work required.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (aa049af): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking 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 Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.5%, secondary -3.2%)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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 760.03s -> 763.804s (0.50%) |
@wesleywiser Hello. Can you suggest someone who might be able to help me interpret these perf results and determine whether they're "OK enough"? My interpretation is:
If this looks OK to you, I'll regard step 2 of this plan as completed then move onto step 3. There's no need to merge this PR. |
I think the performance results are fine! As you say, there is only one benchmark deemed "significant", it's a secondary benchmark and recent runs on that benchmark have some amount of variance anyway. |
Thanks - closing this PR then, and I'll move onto the next step! |
This is a new version of #127812. Here's what I said last time, which still applies:
This PR is one of the first steps towards arbitrary self types v2, RFC 3519 (#44874). Specifically, it is step 2 of the plan outlined here. That says:
So - this commit isn't useful in itself but we need to determine its performance and any unexpected compatibility problems. That's what this PR is for. We shouldn't necessarily merge it.
Here's what this PR does.
Rust prioritizes method candidates in this order:
Previously, if a suitable candidate was found in one of these earlier categories, Rust wouldn't even move onto probing the other categories.
As part of the arbitrary self types work, we're going to need to change that - even if we choose a method from one of the earlier categories, we will sometimes need to probe later categories to search for methods that we may be shadowing.
This commit adds those extra searches for shadowing, but it does not yet produce an error when such shadowing problems are found. That will come in a subsequent commit, by filling out the 'check_for_shadowing' method.
We're adding the extra searches in a preliminary commit because they are the risky bit. We want to find any functional or performance problems from these extra searches before we proceed with the actual work on arbitrary self types and specifically on extra deshadowing errors.
--
What's different this time relative to #127812? Well, this is a more invasive change to the probing algorithm which hopefully minimizes the amount of work done during the extra probing for shadowed methods. Specifically, we only need to warn about potentially shadowed methods if three conditions are true:
DefId
s)self
type as the shadowed methodReceiver
traits than the shadowed.Previously, we checked these conditions only when a potentially shadowed pick was found. We now apply them during the search process, which should minimize the amount of work required.