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 never closes a list #38739

Closed
whitequark opened this issue Dec 31, 2016 · 11 comments
Closed

rustdoc never closes a list #38739

whitequark opened this issue Dec 31, 2016 · 11 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. 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

@whitequark
Copy link
Member

Consider this comment:

//!  * First, it provides functions to extract fields from sequences of octets,
//!    and to insert fields into sequences of octets. This happens through the `Frame`
//!    and `Packet` families of structures, e.g. [EthernetPacket](struct.EthernetPacket.html).
//!  * Second, in cases where the space of valid field values is much smaller than the space
//!    of possible field values, it provides a compact, high-level representation
//!    of packet data that can be parsed from and emitted into a sequence of octets.
//!    This happens through the `Repr` family of enums, e.g. [ArpRepr](enum.ArpRepr.html).
//!
//! The functions in the `wire` module are designed for robustness and use together with
//! `-Cpanic=abort`. The accessor and parsing functions never panic. The setter and emission
//! functions only panic if the underlying buffer is too small.

There is no way to make rustdoc not add the third paragraph, and everything that follows, into the 2nd list item.

@whitequark
Copy link
Member Author

Workaround: add a </ul> explicitly.

@sanxiyn sanxiyn added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Dec 31, 2016
@pyfisch
Copy link
Contributor

pyfisch commented Jan 3, 2017

Cannot reproduce on rustc 1.16.0-nightly (4ecc85beb 2016-12-28). Anyway try removing one space character before the list items.

@whitequark
Copy link
Member Author

That didn't help. I am using rustc 1.15.0-nightly (daf8c1dfc 2016-12-05).

@whitequark
Copy link
Member Author

@pyfisch
Copy link
Contributor

pyfisch commented Jan 3, 2017

@whitequark Indeed. Use line comments (//! ...) instead of block comments (`/*! ... */) in line 27 to 45 and the list is closed.

@whitequark
Copy link
Member Author

@pyfisch The ergonomics of that is absolutely atrocious for code examples, so I'm not going to. I don't see a reason for rustdoc to exhibit this "action at a distance"; why does a comment way below affect the way a list is closed?

@pyfisch
Copy link
Contributor

pyfisch commented Jan 3, 2017

This is obviously a bug in rustdoc.

why does a comment way below affect the way a list is closed?

I don’t know the inner workings of rustdoc an I am not inclined to research this edge case related to uncommon doc-comment syntax. Maybe you can find the problem yourself in the code?

@GuillaumeGomez
Copy link
Member

Taking a look.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Jul 26, 2017
@QuietMisdreavus
Copy link
Member

QuietMisdreavus commented Sep 29, 2017

This is the same issue as #42760: The code within the /*! block does not have the same indentation as the /// lines before it. Thus, the unindent-comments pass does not strip the leading spaces from the first section. Hoedown gets confused when the stuff after the list isn't completely unindented, so it just gloms all that onto the list. To fix that sample, you can shift everything in the /*! block over by one space.

Some good news, though? The new Pulldown renderer is more strict about what items are part of list items, so it does what you want it to here. (cc #44229)

@kzys
Copy link
Contributor

kzys commented Aug 25, 2018

Resolving?

@GuillaumeGomez
Copy link
Member

I removed lists iirc so yes definitely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. 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

No branches or pull requests

8 participants