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

Documentation block comments always become doctests if indented too much #100225

Open
gThorondorsen opened this issue Aug 7, 2022 · 3 comments
Open
Labels
D-confusing Diagnostics: Confusing error or lint that should be reworked. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@gThorondorsen
Copy link

In a project of mine, I use the following convention for doc comments (indentation is ____):

____/** Short description

____Long description
____ */

When indented by 5 spaces or more (i.e. 4 more than appear after /**), the Long description part starts getting considered as an indented code block, to be tested as Rust code, despite the comment start /** being at the same indentation level. It happens regardless of whether the empty line contains spaces or not.

I ran into this when I started documenting the fields of struct-like variants in an enum.

Is it possible to fully support this style of doc-comments? I suppose that by the time rustdoc sees the documentation, the type of comment (line or block) and its indentation has been forgotten so it cannot be used by a de-indentation procedure. Would it be possible to special-case the first line and de-indent the others more?1 If block comments cannot be distinguished from line comments, that has the side effect of not considering the following a doctest anymore:

/// Short description
///
///     assert_eq!(2 + 2, 4);

Meta

Possibly-related issues: #59867, #63193, #64162, #88590

I initially discovered the issue on stable version 1.62.1 and confirmed using the playground that it still happens on nightly (1.65.0-nightly, 2022-08-06 2befdef).

Footnotes

  1. I seem to remember that Python does this for its doc-strings.

@jyn514
Copy link
Member

jyn514 commented Aug 9, 2022

@gThorondorsen I believe if you add * at the same indent level as the opening *, it has the behavior you want.

Note to the rustdoc team: any change here is a breaking change and should go through an edition.

@jyn514 jyn514 added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. D-confusing Diagnostics: Confusing error or lint that should be reworked. labels Aug 9, 2022
@GuillaumeGomez
Copy link
Member

I'd be in favor of not changing anything as it would very likely make us shift away from the commonmark spec.

@ethanmsl
Copy link

This is maddening!

Rust already recommends a codefence (```) for code to interact with doctests.
Use of whitespace in documentation shouldn't trigger CI errors and force cfg flags to be used.

Simply indenting to, for example, draw a math diagram or add some text triggers this.

At the very least having some configuration variable somewhere that allow indentation to not be used for determining what doctest should run on would be excellent.

r-bk added a commit to r-bk/tighterror that referenced this issue Apr 12, 2024
The issue with multiline comments is that the `quote` crate simply
places them inside /** */ comment which by markdown rules is considered
as a code block when indented by more than 4 spaces.

I have reported this in cargo project, and the maintainer has explained
root cause of this behavior [1]. As far as I understand from comments on
issue [2] this behavior is not going to change soon in rustdoc.

This commit works around the issue by adding leading " * " to every line
in a multiline doc string. This way `quote` takes the string as-as and
indented code block is avoided.

[1] rust-lang/rust#123853
[2] rust-lang/rust#100225
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-confusing Diagnostics: Confusing error or lint that should be reworked. 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

4 participants