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.

Sign up for GitHub

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

Jump to bottom

Rustdoc: Search shows incorrect paths for enum variants #17457

Closed
mahkoh opened this issue Sep 22, 2014 · 5 comments
Closed

Rustdoc: Search shows incorrect paths for enum variants #17457

mahkoh opened this issue Sep 22, 2014 · 5 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@mahkoh
Copy link
Contributor

mahkoh commented Sep 22, 2014

E.g. http://doc.rust-lang.org/syntax/ast/enum.Expr_.html?search=ExprIndex shows syntax::ast::Expr_::ExprIndex but the correct path is syntax::ast::ExprIndex.
@huonw huonw added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Sep 22, 2014
@gamazeps
Copy link
Contributor

Is it really a bad thing ?
I mean this way we know that ExprIndex belongs to the enum Expr_, plus as the enum name is CamelCase there are no risk to mistake it for a file / folder.
We only gain info with this path, don't we ?

@mahkoh
Copy link
Contributor Author

mahkoh commented Sep 23, 2014

I see no point in using the :: path syntax if the path isn't the real path of the identifier. I was searching for ExprIndex and quickly dismissed the search results because I didn't see a path ending in ast::ExprIndex. Only after manually going to syntax::ast to see why Rustdoc didn't find it did I realize what is going on.

@tomjakubowski
Copy link
Contributor

I imagine this was done originally because variants and types were in different namespaces. Now that they're in the same namespace rustdoc should use the real path as @mahkoh suggested.

@tomjakubowski
Copy link
Contributor

If accepted, rust-lang/rfcs#390 would close this (although some variants might also be re-exported at the same level as the enum).

@tomjakubowski
Copy link
Contributor

This can be closed now that #18481 is merged

lnicola pushed a commit to lnicola/rust that referenced this issue Jun 23, 2024
@bors
Auto merge of rust-lang#17457 - roife:remove-circle, r=Veykril
153a2ba 
fix: ensure there are no cycles in the source_root_parent_map

See rust-lang#17409

We can view the connections between roots as a graph. The problem is that this graph may contain cycles, so when adding edges, it is necessary to check whether it will lead to a cycle.

Since we ensure that each node has at most one outgoing edge (because each SourceRoot can have only one parent), we can use a disjoint-set to maintain the connectivity between nodes. If an edge’s two nodes belong to the same set, they are already connected.

Additionally, this PR includes the following three changes:

1. Removed the workaround from rust-lang#17409.
2. Added an optimization: If `map.contains_key(&SourceRootId(*root_id as u32))`, we can skip the current loop iteration since we have already found its parent.
3. Modified the inner loop to iterate in reverse order with `roots[..idx].iter().rev()` at line 319. This ensures that if we are looking for the parent of `a/b/c`, and both `a` and `a/b` meet the criteria, we will choose the longer match (`a/b`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@steveklabnik @tomjakubowski @huonw @mahkoh @gamazeps