-
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
rustdoc: intra-doc link errors give incorrect spans on certain block doc comments #55964
Labels
A-intra-doc-links
Area: Intra-doc links, the ability to link to items in docs by name
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
Comments
QuietMisdreavus
added
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
A-intra-doc-links
Area: Intra-doc links, the ability to link to items in docs by name
labels
Nov 15, 2018
I'm working on this. |
You can also reproduce this with unsugared docs:
|
euclio
added a commit
to euclio/rust
that referenced
this issue
Nov 19, 2018
This commit improves the calculation of code spans for intra-doc resolution failures. All sugared doc comments should now have the correct spans, including those where the comment is longer than the docs. It also fixes an issue where the spans were calculated incorrectly for certain unsugared doc comments. The diagnostic will now always use the span of the attributes, as originally intended. Fixes rust-lang#55964.
kennytm
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Dec 5, 2018
…reavus fix intra-link resolution spans in block comments This commit improves the calculation of code spans for intra-doc resolution failures. All sugared doc comments should now have the correct spans, including those where the comment is longer than the docs. It also fixes an issue where the spans were calculated incorrectly for certain unsugared doc comments. The diagnostic will now always use the span of the attributes, as originally intended. Fixes rust-lang#55964.
euclio
added a commit
to euclio/rust
that referenced
this issue
Dec 11, 2018
This commit improves the calculation of code spans for intra-doc resolution failures. All sugared doc comments should now have the correct spans, including those where the comment is longer than the docs. It also fixes an issue where the spans were calculated incorrectly for certain unsugared doc comments. The diagnostic will now always use the span of the attributes, as originally intended. Fixes rust-lang#55964.
bors
added a commit
that referenced
this issue
Dec 12, 2018
fix intra-link resolution spans in block comments This commit improves the calculation of code spans for intra-doc resolution failures. All sugared doc comments should now have the correct spans, including those where the comment is longer than the docs. It also fixes an issue where the spans were calculated incorrectly for certain unsugared doc comments. The diagnostic will now always use the span of the attributes, as originally intended. Fixes #55964. r? @QuietMisdreavus
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-intra-doc-links
Area: Intra-doc links, the ability to link to items in docs by name
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
Given the following source:
The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report:
Strangely enough, putting either the leading
/**
or the closing*/
on its own line will cause the report to change to something that looks correct, if a little too broad:I believe the code at fault is this section here:
rust/src/librustdoc/passes/collect_intra_doc_links.rs
Lines 521 to 538 in 6f244c9
Because it assumes that every doc comment will have a padding of 3 characters (the
///
or//!
), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.The text was updated successfully, but these errors were encountered: