Make lowering incremental, take 3/N#142830
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (a6b131d): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 10.5%, secondary 10.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.5%, secondary 4.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.1%, secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 690.042s -> 689.298s (-0.11%) |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (31325ff): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 10.8%, secondary 10.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.1%, secondary 4.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.1%, secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 689.082s -> 688.79s (-0.04%) |
| self.insert(id, AstOwner::NestedUseTree(parent)); | ||
| items.push(self.make_dummy(id, span, ItemKind::MacCall)); | ||
|
|
||
| let def_id = self.owners[&id].def_id; |
There was a problem hiding this comment.
Is it necessary to pass parent to this function?
It seems like parent is always equal to this def_id (and refers to the single owner def id of the whole use tree hierarchy).
There was a problem hiding this comment.
it's actually building a real tree instead of everything being a child of the root use tree. the nested_vec contains NodeIds of the nested items, so they resolve to different DefIds, too. This logic matches what was here before and how I remember the logic needing to work
|
r=me after addressing the remaining comments, responding to #142830 (comment), and cleaning up the git history. |
|
Reminder, once the PR becomes ready for a review, use |
Co-authored-by: Camille Gillot <gillot.camille@gmail.com>
|
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. |
|
@bors r=petrochenkov |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing b998449 (parent) -> 89a9993 (this PR) Test differencesShow 116 test diffs116 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 89a99936d9e76a50e8df622e7242190841fd871b --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (89a9993): comparison URL. Overall result: ❌ regressions - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 3.3%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.4%, secondary 2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 524.623s -> 522.035s (-0.49%) |
|
@rustbot label: +perf-regression-triaged This is unavoidable without making this PR bitrot for a long time and much more complex. I have various ideas for improving perf here, which I am pursuing as part of rust-lang/rust-project-goals#620 |
View all comments
Rebase of #88186 that was rebased by #127262
No real change in design, so I'm not expecting a perf miracle.
r? @ghost