-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Populate effective visibilities in 'rustc_resolve' #102026
Conversation
@rustbot ready |
Could you also refactor |
This comment was marked as resolved.
This comment was marked as resolved.
150e9ef
to
26a1d3d
Compare
@rustbot ready |
Also #102026 (comment) wasn't addressed yet. |
@rustbot ready |
@rustbot author |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b8b5cae): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression 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)ResultsThis 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.
CyclesResultsThis 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.
Footnotes |
Ouch, there are some significant performance regressions caused by this. They are bad enough that I think we should consider reverting this PR. @Bryanskiy: did you consider compile times while working on this? Are there possibilities for optimizing the new code? |
This PR implements new functionality, i.e. the compiler has to do more work, so a slight regression would be expected, but probably not this much. We certainly need to check what exactly is a hotspot here. Perhaps fully private items are visited too much and that can be avoided by pruning them early, or perhaps it's something else. |
Perf improvements for effective visibility calculating related to rust-lang#102026 r? `@petrochenkov`
Great news! |
Perf improvements for effective visibility calculating related to rust-lang/rust#102026 r? `@petrochenkov`
…omez rustdoc: Simplify modifications of effective visibility table It is now obvious that rustdoc only calls `set_access_level` with foreign def ids and `AccessLevel::Public`. The second commit makes one more step and separates effective visibilities coming from rustc from similar data collected by rustdoc for extern `DefId`s. The original table is no longer modified and now only contains local def ids as populated by rustc. cc rust-lang#102026 `@Bryanskiy`
rustc_metadata: Encode even less doc comments The fact that `def_id` is in the `tcx.privacy_access_levels(())` table is not very meaningful, especially after rust-lang#102026, `is_exported` (or `is_reachable` in the worst case) is what you need. Follow up to rust-lang#98450. r? `@GuillaumeGomez` `@lqd`
rustdoc: Simplify modifications of effective visibility table It is now obvious that rustdoc only calls `set_access_level` with foreign def ids and `AccessLevel::Public`. The second commit makes one more step and separates effective visibilities coming from rustc from similar data collected by rustdoc for extern `DefId`s. The original table is no longer modified and now only contains local def ids as populated by rustc. cc rust-lang/rust#102026 `@Bryanskiy`
rustc_metadata: Encode even less doc comments The fact that `def_id` is in the `tcx.privacy_access_levels(())` table is not very meaningful, especially after rust-lang/rust#102026, `is_exported` (or `is_reachable` in the worst case) is what you need. Follow up to rust-lang/rust#98450. r? `@GuillaumeGomez` `@lqd`
resolve: More detailed effective visibility tracking for imports Per-`DefId` tracking is not enough, due to glob imports in particular, which have a single `DefId` for the whole glob import item. We need to track this stuff per every introduced name (`NameBinding`). Also drop `extern` blocks from the effective visibility table, they are nominally private and it doesn't make sense to keep them there. Later commits add some debug-only invariant checking and optimiaztions to mitigate regressions in rust-lang#103965 (comment). This is a bugfix and continuation of rust-lang#102026.
…nkov Populate effective visibilities in 'rustc_resolve' Next part of RFC rust-lang#48054. previous: rust-lang#101713 `@rustbot` author r? `@petrochenkov`
Next part of RFC #48054.
previous: #101713
@rustbot author
r? @petrochenkov