(Read-only) access to crate code in proc-macro

libs
1

Currently proc-macros can only access the code they are applied to. It would be nice if proc-macros could access the entire crate's code, possibly in a read-only state. This is similar to C# source-generators, though adding extra files wouldn't fall under this suggestion. There is ofcourse the topic of 'what version of code should it be given', to which I personally think it should be all code before any proc-macros ran.

Similar functionality to this is already provided by crates like macro_magic, but a native way to do so would be way better than trying to work around the current proc-macro system.

2

This would require rust-analyzer to re-run all macros whenever any part of any source file is changed, no?

3 Likes
3

This same problem was faced by the .NET team, they made ways to work around this by having separate 'stages', where said stages can be compared to see if source code the generator is actually interested in has changed. See Incremental Generators. A feature like this would require a fair bit of work though. Perhaps there might be some way for the proc-macro to indicate what code it is interested in, C# uses attributes in combination with SyntaxProvider.ForAttributeWithMetadataName for this.

4

Meanwhile, don’t forget build.rs exists! It’s definitely not perfect, but it’s at least an option for things like this. (And for you to see how unhappy rust-analyzer gets if you make your build.rs depend on all the source code in the project.)

1 Like
5

I mean, to what extent can a build.rs file really do this? It:

  • Can only access raw text, not token streams like proc-macros can.
  • It is fairly limited in terms of ability, for example it cannot change source code (again, other than editing the raw text files, which is usually far from ideal compared to the way proc-macros allow you to change code)
  • It is not distributable like proc-macros are
6

A build script can parse Rust source with proc-macro2; it can emit a separate source file found by include! (this is how prost-build works, for example); and it can be packaged as a library referenced in build-dependencies (again, prost-build). Parsing from scratch certainly isn't ideal, but depending on what you want to do it might still be the right choice.

1 Like
7

While I see how that could work; I still see it as a very suboptimal/inconvenient way.
The goal of this suggestion is also not just for my usecase(s), it's more meant as a suggestion for a feature everyone could use.
I think there are a decent number of people out there that could really use this feature, take for example just the 3,701,403 downloads the magic_macro crate has gotten.
Additionally, crates like prost-build are meant more for external files not included in compilation, not source code files.