Skip to content
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

rustdoc: Remove implicit collect in simplify::where_clauses #92296

Closed
wants to merge 2 commits into from
Closed

rustdoc: Remove implicit collect in simplify::where_clauses #92296

wants to merge 2 commits into from

Conversation

vacuus
Copy link
Contributor

@vacuus vacuus commented Dec 26, 2021

No description provided.

@rustbot rustbot added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Dec 26, 2021
@rust-highfive
Copy link
Collaborator

r? @CraftSpider

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 26, 2021
@rust-log-analyzer

This comment has been minimized.

@vacuus
Copy link
Contributor Author

vacuus commented Dec 26, 2021

Admittedly, I'm not good at judging lifetimes. Would rearranging the clauses.extend(...) statements resolve this? However, even if it does, I don't know if the current ordering is important; best for y'all who are knowledgeable in rustdoc to judge that. Alternatively, the extend statement for params could use .iter() instead and copy/clone where necessary, but that might cast the performance gain of this PR in doubt. If neither of these would work out (unless there happens to be a different solution), I'll close the PR.

@CraftSpider
Copy link
Contributor

Moving equalities before params may resolve the move while borrowed issue, but I'm not familiar enough with the code to say whether that would cause a functionality change. At a glance, try reordering them and if it works and passes all tests, I'd suspect it's fine.

@CraftSpider
Copy link
Contributor

Looking into the code deeper, it looks like this may change the order of bounds in the output. No test appears to capture this, I'm not sure if this is considered acceptable breakage. I approve the code changes otherwise though, so I'll delegate to someone who's more familiar with the frontend.

r? GuillaumeGomez

@CraftSpider
Copy link
Contributor

Whoops
r? @GuillaumeGomez

@GuillaumeGomez
Copy link
Member

@CraftSpider raised a very good point. I recently worked on this in #89098. I didn't add a test then for whatever reason so I'll add so we can be sure it's not breaking anything.

@camelid
Copy link
Member

camelid commented Dec 27, 2021

@GuillaumeGomez the reason you didn't add the test is because of #89098 (comment). Now that we have HTML snapshot tests, just add this line (you can assign me on the PR):

// @snapshot where_clause - '//*[@id="implementors-list"]//span[@class="where fmt-newline"]'

@@ -73,6 +73,7 @@ crate fn where_clauses(cx: &DocContext<'_>, clauses: Vec<WP>) -> Vec<WP> {
clauses.extend(
lifetimes.into_iter().map(|(lt, bounds)| WP::RegionPredicate { lifetime: lt, bounds }),
);
clauses.extend(equalities.map(|(lhs, rhs)| WP::EqPredicate { lhs, rhs }));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem right; equalities should be after all parameters, not in between lifetimes and generics.

Copy link
Contributor Author

@vacuus vacuus Dec 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally had an alternate approach:

...the extend statement for params could use .iter() instead and copy/clone where necessary

but I just realized that params is borrowed mutably in the retain (filter, in this PR) call, so it wouldn't work. It seems like I'll have to close this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also not quite sure what the purpose of this PR is. Could you elaborate what you mean by "implicit collect"?

Copy link
Contributor Author

@vacuus vacuus Dec 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was under the impression that the retain call iterates through the collection, filters, and implicitly collects the elements that are supposed to remain. (Though I remembered seeing #91497, so retain seemed even less desirable even if it didn't implicitly call collect.) In any case, I had hoped to avoid anything beyond the necessary costs of iterating and filtering.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of retain is that it just moves memory around; there shouldn't be any implicit collects. However, this rustdoc code does iterate twice.

This code could probably be cleaned up in a way that would improve the performance, but it'd likely be a larger change than just this. So I'm going to close this PR for now. Please feel free to re-open it (or open a new PR) if you find a way to get it working.

@camelid
Copy link
Member

camelid commented Dec 28, 2021

Closing due to #92296 (comment).

@camelid camelid closed this Dec 28, 2021
@vacuus vacuus deleted the simplify-where-clauses branch April 8, 2022 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants