Skip to content

Conversation

cyrgani
Copy link
Contributor

@cyrgani cyrgani commented Oct 3, 2025

Revival of #134401, as a prerequisite for #130856.

This tries to implement the design outlined in #134401 (comment).

r? @tgross35

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 3, 2025
@bjorn3
Copy link
Member

bjorn3 commented Oct 3, 2025

This tries to implement the design outlined in #134401 (comment).

An alternative way to implement #130856 I think would be to have just another server impl that uses the bridge similar to what rustc does. That seems to me like it would avoid unnecessary abstraction. Basically have a function that calls Client::expand1(some_proc_macro_func).run(&SameThread, NoRustcServer::new(), input, true) with NoRustcServer containing all code to run the proc macro outside rustc. Or maybe not exactly that to allow functions that are not exactly shaped like proc macros with a TokenStream input and output, but at least something that internally sets up all thread local storage to register NoRustcServer as the server to communicate with in the place of rustc.

@bors
Copy link
Collaborator

bors commented Oct 8, 2025

☔ The latest upstream changes (presumably #147475) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants