Use per-parent disambiguators everywhere#155547
Use per-parent disambiguators everywhere#155547rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Conversation
This comment has been minimized.
This comment has been minimized.
2690113 to
eaaf4bb
Compare
|
per parent logic is definitely the right thing, and we should take small hits now to clean all that up. |
This comment has been minimized.
This comment has been minimized.
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
070d246 to
910edf3
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
|
@rustbot ready Lets try run perf, a lot of things have changed. |
This comment has been minimized.
This comment has been minimized.
|
@bors try @rust-timer queue The changes seemed innocent enough, but yea, there have been surprises in this are before |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
(Please also squash commits before merging.) |
|
This looks sort of messy now compared to what we have on master, I guess it's the cost of using |
I think it should get better once I do the cleanups mentioned earlier in this PR. |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (07b9436): comparison URL. Overall result: no relevant changes - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary 1.7%, secondary 1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.1%, secondary 3.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 490.352s -> 489.481s (-0.18%) |
b7070f3 to
2e6a082
Compare
|
@rustbot ready |
|
@bors r+ rollup |
…uwer Rollup of 5 pull requests Successful merges: - #155546 (Improve E0308 error message for `impl Trait` return mismatches) - #152834 (Fix incorrect `let` to `const` suggestion for pattern bindings) - #155425 (Remove duplicated `Flags` methods.) - #155547 (Use per-parent disambiguators everywhere) - #155590 (Remove AttributeLintKind variants - part 5)
Rollup merge of #155547 - aerooneqq:better-disambiguators, r=oli-obk Use per-parent disambiguators everywhere This PR addressing the following concerns about per-parent disambiguators (#153955): - DisambiguatorState is removed, PerParentDisambiguatorState is now used everywhere, - Steals were removed from every per-parent disambiguator in resolver, - It adds `parent` field in `PerParentDisambiguatorState` in `#[cfg(debug_assertions)]` for asserting that per-parent disambiguator corresponds to the same `LocalDefId` which is passed into `create_def`, - ~Removes `Disambiguator` trait replacing it with `Disambiguator` enum, with this change we no longer expose `next` method (as trait should be public otherwise the warning will be emitted). It may affect perf in a negative way though.~ ~Those changes should not fix perf issues that were [reported](#153955 (comment)), perf run that was attempted [before](#153955 (comment)) showed much better results. Performance can be probably fixed by removing per-parent disambiguators replacing them with a single one as it was before, then it will be passed to AST -> HIR lowering and modified. For delayed owners we can store ~followup disambiguators as it was in the beginning of the #153955~ per-parent disambiguators. This solution should save achievements from #153955 (removed `DefPathData` variants). However, I would prefer to keep per-parent disambiguators as it seems a better architectural solution for me.~ r? @petrochenkov cc @oli-obk
View all comments
This PR addressing the following concerns about per-parent disambiguators (#153955):
parentfield inPerParentDisambiguatorStatein#[cfg(debug_assertions)]for asserting that per-parent disambiguator corresponds to the sameLocalDefIdwhich is passed intocreate_def,RemovesDisambiguatortrait replacing it withDisambiguatorenum, with this change we no longer exposenextmethod (as trait should be public otherwise the warning will be emitted). It may affect perf in a negative way though.Those changes should not fix perf issues that were reported, perf run that was attempted before showed much better results. Performance can be probably fixed by removing per-parent disambiguators replacing them with a single one as it was before, then it will be passed to AST -> HIR lowering and modified. For delayed owners we can storefollowup disambiguators as it was in the beginning of the #153955per-parent disambiguators. This solution should save achievements from #153955 (removedDefPathDatavariants).However, I would prefer to keep per-parent disambiguators as it seems a better architectural solution for me.
r? @petrochenkov
cc @oli-obk