Add test for and fix issue #6927.#6928
Conversation
rustbot
added
the
S-waiting-on-review
There was a problem hiding this comment.
First, I think we should finish the discussion in #6927 to decide on the behavior before more work is done on this PR.
upon flattening an import tree rustfmt repeats the attributes of the original use statement for all the new ones. This makes sense, and in case of #[cfg...] attributes it's essential.
You acknowledge that the #[cfg...] case is essential, but don't add any test cases for it. Specifically I'd want to see cases where #[cfg] and /// doc comments are used together. Since /// doc comment is just syntax sugar for #[doc = r" This is a doc comment."] I'd also expect to see test cases that use the doc attribute.
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
ytmimi
added
the
S-on-hold
|
@rustbot author |
vgaspary
force-pushed
the
ig_item_rustdoc_conflict
branch
from
2f39613 to
2698e69
Compare
rustdoc comments. `rustc_ast::ast::Attribute` represents both attributes (`#[...]`) and rustdoc comments (`///...`). When flattening an import tree, it makes sense to repeat the attributes for each item. Rustdoc comments, however, don't make sense for each item. Fixes issue#6927.
vgaspary
force-pushed
the
ig_item_rustdoc_conflict
branch
from
2698e69 to
d974229
Compare
|
See #6927 (comment) |
rustbot
removed
the
S-waiting-on-author
ytmimi
removed
the
S-on-hold
3 participants
The root cause for the issue is that upon flattening an import tree
rustfmtrepeats the attributes of the originalusestatement for all the new ones. This makes sense, and in case of#[cfg...]attributes it's essential.The problem occurs because
rustc_asttreats rustdoc comments as attributes too, with therustc_ast::ast::Attributetype.Luckily, it has an
is_doc_commentfunction. The fix uses that to partition the attributes into rustdoc comments and the rest, and then clone the rest for all new use statements, while keeping the comments only with the first one.