Does this refer specifically to macro definitions, to macro invocations, or both?
I must say I find at least the idea of formatting macro invocations a bit concerning as they may include syntax that is not valid Rust or may not even be close to it. Thus, rustfmt could never have the general understanding of all macro based EDSLs to faithfully format them taking into account the domain in which they are used. Keep in mind that a macro, in the general case, essentially describes a new guest language that is using a host language, Rust. It makes sense to me that rustfmt should not format a guest language.
One issue I’ve noticed with futures is that both rustfmt and cargo fix fail to do much because a lot of the code is hidden inside an if_std macro call. This is one macro that guarantees its argument must be valid rust code since it uses an item matcher.
I’m using rustfmt in a few places with nom parsers (which use a lot of macro invocations), and have indeed gone straight to disabling rustfmt for those modules, since it completely obfuscated my neatly formatted nom invocations. So ideally rustfmt should become a bit more conservative about this.
Maybe this is a naive oversimplification, but it seems like the best we could even theoretically do is:
macro definitions get formatted just like any other code, since rustfmt should be able to understand them
by default, rustfmt never touches the stuff inside a macro invocation
assuming there are enough common use cases (probably not a debate we need to have right now), we add some kind of #[rustfmt::valid_rust_code] attribute to parameters in a macro definition, which permits rustfmt to assume arguments in macro invocations must be valid Rust, and therefore should be formatted the same as it would be outside of a macro invocation
for any macro argument that isn’t supposed to be valid Rust, there’s simply nothing rustfmt could realistically do; trying to provide a way for macro authors to define formatting rules for their EDSLs seems like far more trouble than it’s worth
Is that more or less what everyone else had in mind, or is there an actual controversy as to what the long-term plan should be? (as opposed to frustrations with bugs that simply need to be fixed and haven’t yet been fixed)
Perhaps this isn't an impossible/bad idea? Something along the lines of "TexMate" might be of help here? But, It definitely should not be a priority/thing to worry about now.
I was thinking more along the lines of “if we ever do get demand for this, it should be an external tool for a while before we even talk about how to make rustfmt do it”.
Since I’ve never written a proc macro or played around with the syn/quote/etc crates, I guess I should ask: do we have the machinery we need for people to (relatively easily) write such an external macro formatting tool?
Your proposed mechanism makes sense to me; I guess it can live under #[rustfmt::rust_code] for a while as a "semver exempt" feature that is unstable (sorta feature gates for rustfmt). That way you can reuse all the machinery and we get more users that can test it out and see out it pans out.