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

Markdown fails to be interpreted after #[doc] attribute is used #42760

Closed
SergioBenitez opened this issue Jun 20, 2017 · 3 comments · Fixed by #44781
Closed

Markdown fails to be interpreted after #[doc] attribute is used #42760

SergioBenitez opened this issue Jun 20, 2017 · 3 comments · Fixed by #44781
Labels
C-bug Category: This is a bug. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@SergioBenitez
Copy link
Contributor

Consider the following structure with documentation:

/// Item docs.
///
#[doc="Hello there!"]
///
/// # Example
///
/// ```rust
/// // some code here
/// ```
pub struct NonGen;

At present, rustdoc will render this as:

Item docs.

Hello there!

# Example

// some code here

When the following is expected:

Item docs.

Hello there!

Example

// some code here

In short, after a #[doc] attribute, a markdown header is not interpreted as markdown.

This also applies to headers declared using ===, where

Example
=======

is rendered by rustdoc as:

Example =======

as opposed to the expected:

Example

I wouldn't be surprised if this is a more systemic issue and additional markdown syntax is interpreted literally as well.

@steveklabnik steveklabnik added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. labels Jun 20, 2017
@Havvy
Copy link
Contributor

Havvy commented Jul 11, 2017

I would have expected that to be an error TBH.

@QuietMisdreavus
Copy link
Member

A conversation on IRC (that i wasn't actually part of >_>) leads me to provide some background:

Rustdoc has a few passes it performs on doc comments before it hands the text to the markdown processor. The ones relevant to this discussion are collapse-docs (which combines multiple #[doc] attributes into a single body text) and unindent-comments (which strips leading indentation from the doc body text if every line has that same indentation).

The former is what @Havvy was thinking of, since it implies that rustc totally allows multiples of the same attribute on the same item. As a single /// doc comment desugars into a single #[doc=" doc comment"] attribute, this combines the attributes together into a single body of text that can be processed.

However, the latter is what is really at fault here. SpaceManiac on IRC suggested adding a leading space to the spliced-in doc attribute, and that allows the whole doc text to be handled correctly. Without that leading space there, unindent-comments sees a line with no leading indentation on it, and thus does not strip any leading spaces from the entire text. It's as if you were writing the text like this:

/// Item docs.
///
///Hello there!
///
/// # Example
///
/// ```rust
/// // some code here
/// ```
pub struct SomeStruct;

Note at the "Hello there!" line does not have a leading space on it.

I would assume that by the time rustdoc sees all the docs, it doesn't have any indication of whether the line came from a doc comment or a raw doc attribute. If the compiler has that information, then it may be possible to pass that over to rustdoc, which can then ignore "raw doc attributes" in the unindent-comments pass.

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 27, 2017
@GuillaumeGomez
Copy link
Member

I'll take a look once I have enough time.

bors added a commit that referenced this issue Nov 22, 2017
rustdoc: include external files in documentation (RFC 1990)

Part of rust-lang/rfcs#1990 (needs work on the error reporting, which i'm deferring to after this initial PR)

cc #44732

Also fixes #42760, because the prep work for the error reporting made it easy to fix that at the same time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants