-
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
doc attribute removes whitespace #70732
Comments
As explained on discord,
|
How can an attribute get applied to a doc comment? Both are, under the hood, attributes, no? I would expect that to be equivalent to expecting I'm guessing what is true is that |
Simplified reproducer //! ```rust
//! foo();
#![doc = " bar();"]
//! ```
Checking with 1.31.0 it still ignores it (so likely not #65750 related), but checking with 1.21.0 (and 1.0.0) it worked as expected, so somewhere within that range (but I don't have any other versions installed at the moment to check). |
Compilation broke somewhere between
I tested it with //! ```rust
//! let x = r#"
#![doc = " bar();"]
//! "#;
//! assert_eq!(x, "\n bar();\n");
//! ```
|
They are not supposed to be applied to a doc comment
I do not think that. Your example would make sense for #[cfg(foo)]
/// doc comment
struct Example; which I also consider to be wrong, but I am talking about #[cfg_attr(foo, derive(Debug))]
struct Bar; but that is not the point. It might help to illustrate my thought process; We have some kind of documented item: /// ```rust
/// let example = Example::new()
/// .first()
/// .build();
/// ```
struct Example; and each of those
https://doc.rust-lang.org/reference/comments.html#doc-comments #[doc = "```rust"]
#[doc = "let example = Example::new()"]
#[doc = " .first()"]
#[doc = " .build();"]
#[doc = "```"]
struct Example; In a later step those attributes would then be concatenated and parsed as markdown or whatever. I want to use this behavior to document items conditionally, depending on which features the crate user has enabled. One way to do this would be to do #[cfg_attr(
not(feature = "one"),
doc = r#"```rust
let example = Example::new()
.first()
.build();
```"#
)]
#[cfg_attr(
feature = "one",
doc = r#"```rust
let example = Example::new()
.first()
.second()
.build();
```"#
)]
struct Example; but that would blow up the source code with many duplicate lines, where only some minor things were changed. So I thought that it might make more sense to conditionally include a doc comment like this: /// ```rust
/// let example = Example::new()
/// .first()
#[cfg_attr(feature = "one", doc = " .second()")]
/// .build();
/// ```
struct Example; which would turn into #[doc = "```rust"]
#[doc = "let example = Example::new()"]
#[doc = " .first()"]
#[doc = " .second()"]
#[doc = " .build();"]
#[doc = "```"]
struct Example; or #[doc = "```rust"]
#[doc = "let example = Example::new()"]
#[doc = " .first()"]
#[doc = " .build();"]
#[doc = "```"]
struct Example; depending on whether the feature is enabled. So the attribute should not be inserted and not applied to the following doc comment. The weird thing is that the manually expanded version is working as expected. #[doc = "```rust"]
#[doc = "let example = Example::new()"]
#[doc = " .first()"]
#[cfg_attr(feature = "one", doc = " .second()")]
#[doc = " .build();"]
#[doc = "```"]
pub struct WorkingExample; but this is very unhandy to work with :/ |
I was randomly looking at passes for another reason and noticed what is likely the source of this issue. There are two relevant passes:
|
Fix unindent in doc comments Fixes rust-lang#70732 r? `@jyn514`
I tried this code:
with
cargo doc --open
I expected to see this:
Instead, this happened:
Meta
rustc --version --verbose
:running
cargo expand
over the code gives meThe text was updated successfully, but these errors were encountered: