You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a doc comment of a trait item begins with a code block, it will be changed to inline code in implementations of that trait, which leads to weird formatting.
Example
pubtraitTraitExample{/// Some text.////// ```/// let a = 0;/// ```fna(){}/// ```/// let b = 0;/// ```fnb(){}/// ```rust/// let c = 0;/// ```fnc(){}/// ```/// // Comment `example`./// let d = 0;/// ```fnd(){}}pubstructStructExample;implTraitExampleforStructExample{}
Here is what it looks like in the implementation for StructExample:
The docs for the method a work as expected.
The code block of method b is changed to inline code.
The code block of method c is also changed to inline code and the word rust is shown in the inline code instead of specifying the syntax. There is also a trailing whitespace which is not present in the original code block.
In the docs of d the backticks of the word example end the main inline code.
While the inline code looks fine in simple examples (e.g. docs of method b), the format is confusing in most cases. The expected behaviour would probably be that the code block does not get converted to inline code.
Example in std
Another example for this behaviour can be seen in the description method of std::error::Error. The docs of the method begin with a code block and then get changed to inline code in the implementations.
Documentation in std::error::Error:
Documentation of the implementation in std::io::Error:
nn1ks
changed the title
Rustdoc generates weird formatting of code blocks in trait implementations
Rustdoc changes code blocks to inline code in trait implementations
Jun 18, 2020
…illaumeGomez
rustdoc: do not use plain summary for trait impls
Fixesrust-lang#38386.
Fixesrust-lang#48332.
Fixesrust-lang#49430.
Fixesrust-lang#62741.
Fixesrust-lang#73474.
Unfortunately this is not quite ready to go because the newly-working links trigger a bunch of linkcheck failures. The failures are tough to fix because the links are resolved relative to the implementor, which could be anywhere in the module hierarchy.
(In the current docs, these links end up rendering as uninterpreted markdown syntax, so I don't think these failures are any worse than the status quo. It might be acceptable to just add them to the linkchecker whitelist.)
Ideally this could be fixed with intra-doc links ~~but it isn't working for me: I am currently investigating if it's possible to solve it this way.~~ Opened rust-lang#73829.
EDIT: This is now ready!
If a doc comment of a trait item begins with a code block, it will be changed to inline code in implementations of that trait, which leads to weird formatting.
Example
Here is what it looks like in the implementation for
StructExample
:The docs for the method
a
work as expected.The code block of method
b
is changed to inline code.The code block of method
c
is also changed to inline code and the wordrust
is shown in the inline code instead of specifying the syntax. There is also a trailing whitespace which is not present in the original code block.In the docs of
d
the backticks of the wordexample
end the main inline code.While the inline code looks fine in simple examples (e.g. docs of method
b
), the format is confusing in most cases. The expected behaviour would probably be that the code block does not get converted to inline code.Example in
std
Another example for this behaviour can be seen in the
description
method ofstd::error::Error
. The docs of the method begin with a code block and then get changed to inline code in the implementations.Documentation in
std::error::Error
:Documentation of the implementation in
std::io::Error
:More examples:
std::io::Error
(stable, nightly),std::num::ParseIntError
(stable, nightly).Meta
I ran
rustdoc
/cargo doc
in both stable and nightly which all generated the same result.rustdoc --version --verbose
:rustdoc --version --verbose
:The text was updated successfully, but these errors were encountered: