Given the following source:
/** # for example,
*
* time to introduce a link [error]*/
pub struct SomeStruct;
The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report:
$ cargo +nightly doc
Documenting asdf v0.1.0 (/home/misdreavus/git/asdf)
warning: `[error]` cannot be resolved, ignoring it...
--> src/lib.rs:3:33
|
3 | time to introduce a link [error]*/
| _________________________________^
4 | | pub struct SomeStruct;
| |__^ cannot be resolved, ignoring
|
= note: #[warn(intra_doc_link_resolution_failure)] on by default
= help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
Finished dev [unoptimized + debuginfo] target(s) in 2.12s
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:
/**
* # for example,
*
* time to introduce a link [error]
*/
pub struct SomeStruct;
$ cargo +nightly doc
Documenting asdf v0.1.0 (/home/misdreavus/git/asdf)
warning: `[error]` cannot be resolved, ignoring it...
--> src/lib.rs:1:1
|
1 | / /**
2 | | * # for example,
3 | | *
4 | | * time to introduce a link [error]
5 | | */
| |___^
|
= note: #[warn(intra_doc_link_resolution_failure)] on by default
= note: the link appears in this line:
time to introduce a link [error]
^^^^^
= help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
Finished dev [unoptimized + debuginfo] target(s) in 2.12s
I believe the code at fault is this section here:
|
let line_offset = dox[..link_range.start].lines().count(); |
|
// The span starts in the `///`, so we don't have to account for the leading whitespace |
|
let code_dox_len = if line_offset <= 1 { |
|
doc_comment_padding |
|
} else { |
|
// The first `///` |
|
doc_comment_padding + |
|
// Each subsequent leading whitespace and `///` |
|
code_dox.lines().skip(1).take(line_offset - 1).fold(0, |sum, line| { |
|
sum + doc_comment_padding + line.len() - line.trim().len() |
|
}) |
|
}; |
|
|
|
// Extract the specific span |
|
let sp = sp.from_inner_byte_pos( |
|
link_range.start + code_dox_len, |
|
link_range.end + code_dox_len, |
|
); |
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.
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.