Cache and use more ModId - #159787
Conversation
We generally expect Visibility to have ModId or LocalModId, so it seems good to restrict the impls as such. There is just one error path needing adjustment to check that we actually have a ModId. It should be okay since, if it is not a module, an error will be emitted elsewhere.
|
HIR ty lowering was modified cc @fmease |
|
r? @mu001999 rustbot has assigned @mu001999. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@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.
Cache and use more ModId
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (d23ae58): comparison URL. Overall result: ❌ regressions - please read:Benchmarking 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. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 488.274s -> 486.771s (-0.31%) |
|
Seems this instead leads to a slight perf regression. Do you have any ideas? @rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
|
☔ The latest upstream changes (presumably #160506) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
Simplifying code a bit. Perhaps a tiny perf win from less parent module lookups.