Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the remaining unimplemented proc-macro APIs in the proc-macro server #15950

Open
Veykril opened this issue Nov 22, 2023 · 0 comments
Open
Labels
A-proc-macro proc macro C-tracking-issue Category: tracking issue E-unknown It's unclear if the issue is E-hard or E-easy without digging in

Comments

@Veykril
Copy link
Member

Veykril commented Nov 22, 2023

Note: This will have to wait until after my token map rewrite.

We have no issue tracking this yet so I figured making a barebones one should be good for any discussions involved as it is already known that this is gonna be a difficult thing to do.

To describe the problem in simple terms, a lot of the API exposes state of the world to proc-macros, an example being asking for the source of a span. In rustc, this is fine as the proc-macro server runs inside the main rustc process, but in rust-analyzer, the server is a separate process that rust-analyzer communicates to via a a json RPC interface. This worked out fine so far as we only need to ask the server to expand a proc-macro with a given token stream and giving back the expanded one. To serve these unimplemented APIs otoh, we need to allow the server to communicate back to the client (rust-analyzer) to ask for certain information / properties about the program (and potentially in the future even ask about expanding macros which requires name resolution 😭). In theory, this should be straight forward but we might run into problems wrt the client-server architecture of the proc-macro bridge. That's the main open question to solve once this is being worked on.

We also need to be able to inspect our used spans after #15959, so that our syntax fixup stuff can continue working. That is we need to special case the span setting functions such that fixup IDs are not copied over resulting in removed code.

@Veykril Veykril added A-proc-macro proc macro S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work. C-tracking-issue Category: tracking issue labels Nov 22, 2023
@Veykril Veykril added E-unknown It's unclear if the issue is E-hard or E-easy without digging in and removed S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work. labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-proc-macro proc macro C-tracking-issue Category: tracking issue E-unknown It's unclear if the issue is E-hard or E-easy without digging in
Projects
None yet
Development

No branches or pull requests

1 participant