Also annoying is when rust analyser gives you much less info just because you have a macro on a function. For example commenting out a #[tracing:instrument] on a function will enable "extract function" refactor and sometimes show more type inlay hints.
This points to a general issue: that macros are second class when it comes to the developer tooling. It would be good if more uses of macros can be replaced with things that the tooling (RA and rustfmt) understand. Variadics generics would go a long way towards removing a huge class of these uses for example.
Or we could start doing things like being able to mark some macros as various useful points along the spectrum between:
Format and type hint as if the macro wasn't there (tracing instrument)
Format as rust but don't show type inlay hints etc
Totally custom syntax (in the future: allow defining custom grammar for highlighting, custom formatting, etc)
There is precedence for that last one: in webdev it is common to have mixed languages in one file: from php with mixed in html back in the day, to js and css inside html still.
Allowing customised extension points for this sound like a useful feature, but just having a "treat it like normal rust" mode would still be useful.
r-a does understand macros (to the extent possible), some of the bad behaviors with it are inherent but most are just bugs (that you should report!) It does require special care when developing r-a to remember macro edge cases, though, and therefore they often get forgotten.
rustfmt doesn't understand macros and probably never will.
That would make it unbearably slow. cargo fmt is less of a problem, but when I format in my editor, it's a blocking operation and it needs to return fast.
I would not like rustfmt to start getting different results on different platforms based on various options or settings that get selected. Formatting really should be a "text-only" operation at its core. And anything enforcing a "Rust-aware" formatting ruleset will "fight" with any contributors not doing so.
If, hypothetically, we had a version of rustfmt that did name resolution and macro-specific formatting, it would be predictable and behave the same for everyone. There are other reasons to potentially not want to do that, but that isn't one of them.
rustfmt does already leverage parts of the compiler. However, it would be a step above and beyond that to integrate name resolution for cross crate references.
At the risk of starting an intra-project turf war and the caveat that I'm not speaking for the rust-analyzer team (only myself!), I think that if there were to be a formatter that did name resolution and was macro-aware, I think I'd prefer it to live in rust-analyzer so that in-editor latencies were acceptableâwith rustfmt, I've found the tail latencies are less than ideal, albeit through no fault of rustfmt.
In this world, CLI-invoked formatting would either be slower or not aware of macros.
Actually, as another member of the rust-analyzer team on behalf of myself only, I did consider and like the idea of having the formatter we are planning to eventually integrate (maybe) into r-a semantic-aware. However, I'm concerned that this will lead to issues with CI and such, or RustRover, etc..
That's actually not a bad idea. rustfmt could explicitly do nothing, leaving the door open to anyone else (realistically r-a but also possibly other tools). I hadn't considered the speed of rustfmt on save, only CI/standalone formatting and checks.
That's only a viable option if there were also a way to trivially invoke rust-analyzer from the command line and format (or check formatting of) an entire project, in the style of cargo fmt; e.g. cargo afmt. That would be needed for both command-line usage and CI.
(Also, it would need to work on every project without requiring any r-a configuration or setup, since cargo fmt does.)
I don't get the logic of this part. If you can use RA you can use RA format? If your project is so weird that RA doesn't work, then RA format might not work either?
I'm talking about the case where RA works, but needs configuration in order to work. Configuration that rustfmt doesn't need.
I'm enthusiastically in support of having a formatter that could be macro-aware. But only if everyone can trivially use it, whether they use RA or not.
I'm not sure exactly what you are referring to. Do you mean when people aren't using cargo, but some other build system? (E.g. RFL, meson, bazel.) I don't think it is an issue to require a project specific way to run the formatter as well then.
However, I'm concerned that this will lead to issues with CI and such, or RustRover, etc..
I think we can get the formatting functionality to run on CI or RustRover pretty easily! After all, we can run rust-analyzer analysis-stats today; I don't think it'd be unreasonable to extend that to a currently hypothetical rust-analyzer fmt.
That's only a viable option if there were also a way to trivially invoke rust-analyzer from the command line and format (or check formatting of) an entire project, in the style of cargo fmt; e.g. cargo afmt. That would be needed for both command-line usage and CI.
(Also, it would need to work on every project without requiring any r-a configuration or setup, since cargo fmt does.)
I agree! I think we (the rust-analyzer team) can accomplish trivial, "it just worksâ˘" CLI-based formatting for command line or CI use if we (the Rust project as a whole) accept that rust-analyzer wouldn't format macros in a configuration-free setup. I think this is fine because there wouldn't be any user-facing regressions.
However, if folks want macro-aware formatting in addition to the baseline rustfmt-style formatting, I think it is perfectly fair to require some additional setup in order to support name resolution and macro expansion. To be more concrete, the required setup I'm thinking of is rust-analyzer running cargo metadata or invoking Bazel/Buck/etc. in order to get a rust-project.json. Josh, while I'm sure you know this, other readers might notâI've spent a decent chunk of the last four years making the non-Cargo build system experience in rust-analyzer be nearly as polished as the Cargo-based experience, so I feel pretty confident in saying that more exotic setups wouldn't be that hard to support
Are there any custom LSP servers for selected function-like macros (whether procedural or macro_rules)? Especially for macros that take Rust-like input and modify it only slightly, so that (I hope) they could "forward" inlay hint queries to relevant parts of their macro input and (hoping that) rust-analyzer could provide inlay hints for those "forwarded" parts.
Would that be possible? If so, any examples, please?
(slint! doesn't seem to be such a macro. I did look around crates.io: Rust Package Registry but I can't see anything obviously similar.)
