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 incorrectly handles ## #73623

Closed
lcnr opened this issue Jun 22, 2020 · 15 comments
Closed

rustdoc incorrectly handles ## #73623

lcnr opened this issue Jun 22, 2020 · 15 comments
Labels
C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@lcnr
Copy link
Contributor

lcnr commented Jun 22, 2020

I tried this code:

/// ```rust
/// ##![no_std]
/// ```
pub struct A;

with cargo doc

I expected to see this happen: Either an error or #![no_std] gets hidden

What actually happend: The first # gets ignored.
Screenshot from 2020-06-22 17-41-49

@lcnr lcnr added C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jun 22, 2020
@GuillaumeGomez
Copy link
Member

A fix to this issue is present in this PR apparently (or maybe I understood it incorrectly?).

@lcnr
Copy link
Contributor Author

lcnr commented Jul 9, 2020

Not sure, does #74094 change the way # is handled in code snippets?

@GuillaumeGomez
Copy link
Member

I think it does: https://github.com/rust-lang/rust/pull/74094/files#diff-545d93b02fb448fc31d33a6b1e0e0c48R136-R153 At least it's changing the code handling it...

@lcnr
Copy link
Contributor Author

lcnr commented Jul 9, 2020

So it seems like it was a conscious decision to print ##abc as #abc :/

Can we still change this/what was the reason for this decision?
Otherwise this can just be closed as it seems like this behavior is intended.

@GuillaumeGomez
Copy link
Member

Well, I have to admit that it seems weird and I wonder if it isn't just a side-effect more than a desired behavior. What do you think @rust-lang/rustdoc ?

@Mark-Simulacrum
Copy link
Member

See #41785 where the behavior for ## was introduced. If you want to hide #![no_std] you want to use # #![no_std], ##![no_std] is changed to #![no_std] I believe.

@GuillaumeGomez
Copy link
Member

Should we maybe add a lint for it?

@Mark-Simulacrum
Copy link
Member

I am confused -- the behavior may not be entirely intuitive, but linting would seem odd, as either case is entirely reasonable.

@GuillaumeGomez
Copy link
Member

I completely agree but the confusion seems logical. So having a lint you can easily discard might be a good solution to help users when they have such a case, no?

@Mark-Simulacrum
Copy link
Member

I disagree that we should have lints that are (not infrequently) allow'd in rustdoc/rustc; that seems more like clippy territory. It's also true that I don't think we have a good story for allowing lints that rustdoc emits today?

@GuillaumeGomez
Copy link
Member

It's being improved currently, but as far as I can see, the rustdoc lints are fine.

@ollie27
Copy link
Member

ollie27 commented Jul 9, 2020

A lint would be overly complicated for this. The behavior is documented at https://doc.rust-lang.org/nightly/rustdoc/documentation-tests.html#hiding-portions-of-the-example but maybe it can be improved to make it clear that you need a space after the hash for a line to be hidden.

@GuillaumeGomez
Copy link
Member

I didn't even think about the implementation when talking about the lint. It's just that I don't really know how to avoid such a case and help users in case it's a typo. Documentation exists but it's pretty rare for users to actually go read it when they have troubles unfortunately...

@Mark-Simulacrum
Copy link
Member

I think we don't have sufficient cause for this to merit adding a lint - the input on this case isn't valid Rust, nor could it be; as such I would expect it to be quite rare to encounter in practice (and even on accident). It's also harmless if you do want to show the attribute (and if you don't, IMO adding a space is not entirely unintuitive, though I could be wrong about that, seeing as this thread suggests otherwise to some extent).

@GuillaumeGomez
Copy link
Member

Well, this current case is a good example. 😉 But honestly, I feel like any additional check would be overkill here... So I really don't know what to do in here except nothing.

@lcnr lcnr closed this as completed Jul 9, 2020
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-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