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] Detect and resolve ambiguities in fn parameters type names #122872

Closed
wants to merge 6 commits into from

Conversation

krtab
Copy link
Contributor

@krtab krtab commented Mar 22, 2024

Possible improvements could be

  1. Be more clever regarding the size of the full path suffix that must be kept to be unambiguous. This would be better looking, but add code in more places and be more complex algorithmically and at runtime as well I guess.
  2. To use a similar disambiguation wherever else is needed. Off of the top of my head I'd say every time we print a tuple.

A more general way of doing it would add a notion of context to the formatting which keeps track of what symbols are currently being rendered and need disambiguation, but this is a much more ambitious work. EDIT: actually, a simple notion of context is not enough. This needs to be done in two passes. The first one identifies for each symbol its shorter non ambiguous path suffix, and the second does the actual printing.

Closes: #122673

r? @GuillaumeGomez

@rustbot rustbot added 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. labels Mar 22, 2024
Comment on lines 1529 to 1530
.map(|rcb| rcb.get())
.unwrap_or(false);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
.map(|rcb| rcb.get())
.unwrap_or(false);
.is_some_and(|rcb| rcb.get());

) -> FxHashMap<DefId, Rc<Cell<bool>>> {
fn inner(
ty: &clean::Type,
res_map: &mut FxHashMap<DefId, Rc<Cell<bool>>>,
Copy link
Member

Choose a reason for hiding this comment

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

Why do you need to have Rc<Cell<bool>> instead of just a bool?

@fmease fmease changed the title [rustdoc] Detect and resolve amibiguities in fn parameters type names [rustdoc] Detect and resolve ambiguities in fn parameters type names Mar 22, 2024
@krtab krtab marked this pull request as draft March 22, 2024 23:00
@bors
Copy link
Contributor

bors commented Apr 10, 2024

☔ The latest upstream changes (presumably #123725) made this pull request unmergeable. Please resolve the merge conflicts.

self.add_fndecl(&f.decl);
}

pub fn finnish(self) -> AmbiguityTable<'a> {
Copy link
Member

Choose a reason for hiding this comment

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

Northern countries are now part of rust. 😄 ("finnish" with two "n")


pub fn build_fn(f: &'a Function) -> Self {
let mut builder = Self::build();
builder.add_fn(f);
Copy link
Member

Choose a reason for hiding this comment

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

Please directly call add_fn_decl. That will remove one method.

}

#[allow(rustc::pass_by_value)]
pub fn get(&self, x: &DefId) -> Option<&PathLike<'a>> {
Copy link
Member

Choose a reason for hiding this comment

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

Should really not be a reference (DefId).

@@ -0,0 +1,202 @@
use rustc_data_structures::fx::FxHashMap;
Copy link
Member

Choose a reason for hiding this comment

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

Might be worth adding a comment explaining how the path ambiguities are handled at the top of the file.

@@ -878,6 +880,7 @@ fn assoc_const(
indent: usize,
cx: &Context<'_>,
) {
let at = AmbiguityTable::empty();
Copy link
Member

Choose a reason for hiding this comment

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

A lot of AmbiguityTables are created way too "low" in the tree call. For example in here, an associated constant is part of an impl or a trait, so the AmbiguityTable should have been already created much earlier. I think you can simply create one AmbiguityTable in html/render/context.rs::fn render_item and then pass it down everywhere.

}

// @has fn_param_ambiguities/fn.f.html //pre 'pub fn f(xa: X::A, ya: Y::A, yb: B, xc: C)'
pub fn f(xa: X::A, ya: Y::A, yb : Y::B, xc: X::C) {}
Copy link
Member

Choose a reason for hiding this comment

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

Please add struct and other types with impls and do the same for their associated items (like constants, methods and types).

@Dylan-DPC Dylan-DPC added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 3, 2024
@Dylan-DPC
Copy link
Member

@krtab any updates on this? thanks

@Dylan-DPC
Copy link
Member

Closing this based on the comment #42066 (comment)

@Dylan-DPC Dylan-DPC closed this Aug 20, 2024
@Dylan-DPC Dylan-DPC removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

Don't show two different types as the same thing in a single function
5 participants