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 src links link to the wrong place for modules #12926

Closed
brson opened this issue Mar 16, 2014 · 0 comments
Closed

rustdoc src links link to the wrong place for modules #12926

brson opened this issue Mar 16, 2014 · 0 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Mar 16, 2014

The source link for Any links to the module declaration in lib.rs instead of the more useful file, any.rs.

bors added a commit that referenced this issue Apr 28, 2014
This PR is primarily motivated by (and fixes) #12926.

We currently only have a span for the individual item itself and not for the referred contents. This normally does not cause a problem since both are located in the same file; it *is* possible that the contained statement or item is located in the other file (the syntax extension can do that), but even in that case the syntax extension should be located in the same file as the item. The module item (i.e. `mod foo;`) is the only exception here, and thus warrants a special treatment.

Rustdoc would now distinguish `mod foo;` from `mod foo {...}` by checking if the span for the module item and module contents is in different files. If it's the case, we'd prefer module contents over module item. There are alternative strategies, but as noted above we will have some corner cases if we don't record the contents span explicitly.
@bors bors closed this as completed in c8a29c4 Apr 28, 2014
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

No branches or pull requests

1 participant