-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
A fix to this issue is present in this PR apparently (or maybe I understood it incorrectly?). |
Not sure, does #74094 change the way |
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... |
So it seems like it was a conscious decision to print Can we still change this/what was the reason for this decision? |
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 ? |
See #41785 where the behavior for |
Should we maybe add a lint for it? |
I am confused -- the behavior may not be entirely intuitive, but linting would seem odd, as either case is entirely reasonable. |
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? |
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? |
It's being improved currently, but as far as I can see, the rustdoc lints are fine. |
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. |
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... |
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). |
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. |
I tried this code:
with
cargo doc
I expected to see this happen: Either an error or
#![no_std]
gets hiddenWhat actually happend: The first
#
gets ignored.The text was updated successfully, but these errors were encountered: