T-style triage meeting 2025-06-04

--- title: T-style triage meeting 2025-06-04 tags: ["T-style", "triage-meeting", "minutes"] date: 2025-06-04 discussion: https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/meeting.202025-06-04 url: https://hackmd.io/x-4zec9ySzGot9PUAbIhJw --- # T-style meeting agenda - Meeting date: 2025-06-04 ## Attendance - People: TC, Josh, Caleb, Tomas ## Meeting roles - Facilitator: TC - Minutes: Tomas ## Check-in (Not minuted.) ## Handling of bodies in macro arguments TC: Could we add an attribute somewhere, e.g. on macro parameters, to signal to the formatter (and rust-analyzer) when something is a body? Maybe then we'd have to do less special casing then for macros in std. Caleb: rustfmt offloads a lot of this work to the compiler and things around source is not available to rustfmt. Changing that would be a pretty radically large effort. We're not doing name resolution. Rustfmt today looks at the arguments, see if they look like rust code. If the compiler says this seems like e.g. an argument, rustfmt will apply them. Scepticism around attribute-driven formatting. There are tricky scenarios with attribute-driven commands. In the past leaned towards is to maintain this default generic position: if it looks like Rust, format it as Rust. Adding specific rules around macros, we never did that. But we could add rules specific to a given macro (as we do with `matches!`). TC: If we don't have name resolution, how do we know we're looking at e.g. the stdlib `select!` and not another macro. Caleb: If we had an alias or a second impl, this could happen. But now we can see that the ident is in the AST and we use that. Caleb: We basically match on the ident name. We look at the path a bit more holistically but nothing fancy. TC: Say we have an attribute like `rustfmt::skip`. Can we have a use-site attribute and say "do the formatting, this is a body"? Better than not having rustfmt format it at all. Josh: Formatting for some macros is more than just "is this Rust macro". E.g. for config/select we may want to say we want to format something like the `match`. It's not quite Rust code, but we'd like it to look similarly to match. Ability to identify things like to say "this macro is formatted just like format!" and/or match. TC: Emacs has something like this -- where you can configure a list of macros that will be formatted a given way. Caleb: Sounds like you've been reading our issue tracker :-). This is where we're kind of landing. The ability to designate the formatting to treat it like it's an item/expression/whatever. Was describing what rustfmt does today. But if expand the rustfmt capabilities, we won't be locked onto what we have today. TC: It's a heavy limitation that macros not in the standard library don't get formatting support. We're thinking of having a more pluggable/extensible compiler. E.g. being able for libraries to write their own lints. Is there a similarly radical proposal where you could write a plugin that would specify formatting? Josh: Wonder if cargo-fmt could pick up information form a library crate and pass that to rustfmt. Things like, "please format my macro this way" or "apply this rule to things like this". Caleb: https://github.com/rust-lang/rustfmt/issues/8#issuecomment-2334441074 There are concerns around, if we do this, how can we go about doing it. If you allowing this, how do you support things like stability guarantees. What if individual styles end up being posed by authors that end up conflicting. There are macros that do things like HTML. How much should we be supporting macros like this. TC: This comes up all that time. If a library author does something wild, unrusty -- people won't use it. I'm pretty happy to give discression to the ecosystem, and that largely doesn't tend to be the problem. Caleb: The style guide has taken a specific position on subjective and controversial topics. There is still a lot of debate and strong opinions on all side. We're deferring this decision to the individual author. Issue: if the style guide says macros should be formatted a given way and then authors could override, that could result in an incompatible formatting rules. Josh: More suggesting broad things like "this macro takes things that looks like rust code". Or "this macro takes code that looks like rust code in these areas". Have a 6-ish broad rules, not exploding the possibilities. We don't have to choose between absolute control by dependencies vs. absolutely no control. TC: Agree with that. We'd get a lot of milage out of a set of templates. At the same time, I do think we could go further and address the potential problems in other ways. If it's easy for people to say, "format this bit like Rust code", they'll do that. ## Scheduled design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Proposed design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Announcements or custom items (Meeting attendees, feel free to add items here!) ## Nominated RFCs, PRs, and issues ### "`edition.md` is causing many conflicts" style-team#192 **Link:** https://github.com/rust-lang/style-team/issues/192 ### "Style Guide prescriptions on ABI explicitness" style-team#199 **Link:** https://github.com/rust-lang/style-team/issues/199 ### "Styling of Rust Frontmatter" style-team#212 **Link:** https://github.com/rust-lang/style-team/issues/212 ### "Formatting for cfg_match" style-team#201 **Link:** https://github.com/rust-lang/style-team/issues/201 ### "Review of nightly style process" style-team#202 **Link:** https://github.com/rust-lang/style-team/issues/202 ### "Never break between empty parens" style-team#210 **Link:** https://github.com/rust-lang/style-team/issues/210 ### "Improvements to match formatting" style-team#211 **Link:** https://github.com/rust-lang/style-team/issues/211 ## Pending PRs on the style-team repo None. ## RFCs waiting to be merged None. ## `S-waiting-on-team` None. ## Proposed FCPs **Check your boxes!** ### "style-guide: Note that we don't account for comments in every possible place" rust#121762 **Link:** https://github.com/rust-lang/rust/pull/121762 ### "Improvements to match formatting" style-team#211 **Link:** https://github.com/rust-lang/style-team/issues/211 ## Active FCPs ### "Formatting for cfg_match" style-team#201 **Link:** https://github.com/rust-lang/style-team/issues/201 ### "Never break between empty parens" style-team#210 **Link:** https://github.com/rust-lang/style-team/issues/210 ## P-critical issues None. ## Check-out (Not minuted.)