Fn params are commented out with doc comments.

[HyeonuPark]

$ git rev-parse HEAD
3d8cd57c2f166cb92204e95a5f4c73ab20fed4f2

$ cat example.rs
#[discard_params_doc]
trait Trait {
    fn foo(
        &self,
        /// some docs
        bar: String,
        /// another docs
        baz: i32,
    );
}

$ cargo run --bin rustfmt -- --edition=2018 < example.rs 2> /dev/null
#[discard_params_doc]
trait Trait {
    fn foo(&self, /// some docs bar: String, /// another docs baz: i32
    );
}

Normally doc comments on fn params triggers compile error. But it's ok if attribute macro discards it anyway... unless I run rustfmt on it.

[calebcartwright]

Could you please do me a favor and update the issue description with a clean snippet that can be directly reproduced by copying the contents as-is? I appreciate you trying to structure it the way you did, but it actually makes it more difficult to work with.

[HyeonuPark]

I've edited the Issue! Hope it's better for you to handle it. Otherwise please let me know to update it.

[calebcartwright]

Yeah that helps thank you! I don't think it would be too hard for us to work around this but I want to try to verify it's a truly valid scenario. Do you have an example somewhere using such a macro that can be compiled?

[HyeonuPark]

Right, I should attach some real usages of such patterns from the start. Sadly there's no such macro in public I'm aware of. But let me describe my own use case and why do I need it.

Recently I'm making some macro which takes a trait def and generates HTTP server, client code and OpenAPI spec from it. The project is pretty much in its initial stage without much features implemented but that's the plan. The OpenAPI allows to attach markdown descriptions to its API parameters, and I thought it would be natural to use doc comment on each method parameters for it. Quick test on my local was successful, but my editor runs auto-formatting and I found this issue.

If you prefer to have working such macro for testing or for fun, I can share one within this week. It's just a matter of stripping down my local test code.

[calebcartwright]

Fair enough, thanks for the info! It seems like a pretty extreme edge case at the moment but since it's accepted by the compiler's parsing stage (of which the resultant AST is what rustfmt sees/works with) then it's probably fair for us to handle this anyway.

[TonalidadeHidrica]

@calebcartwright Hi, I still saw this bug in rustfmt 1.4.37-stable (f1edd042 2021-11-29). Is this intended?

[calebcartwright]

@calebcartwright Hi, I still saw this bug in rustfmt 1.4.37-stable (f1edd042 2021-11-29). Is this intended?

The closing of issues/merges of PRs in tool repos is not directly coupled to Rust releases. You have to wait a good bit for changes to actually make it into the nightly releases (where you can already observe the fix) and longer still for tool changes to land on stable