You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking issue for plugin stabilization (plugin, plugin_registrar features) #29597
changed the title [-]Tracking issue for `plugin_registrar`[/-][+]Tracking issue for plugin stabilization (`plugin`, `plugin_registrar` features)[/+]on Nov 5, 2015
Is anyone actively working on this? Curious what the status is since using Serde without the need for code generation with syntex on stable Rust is very high on my Rust wishlist. 😃
In particular, check out the discussion here, which points to a bunch of blog posts by @nrc amongst other things. He plans to finish the blog series and post an RFC soon.
Thanks Aaron—I had read a couple of the posts about the macro system but it didn't click that this was intended to replace compiler plugins for the purpose of syntax extensions. It makes sense now, and looks great. I can't wait. :}
The one remaining plugin in Servo is a register_late_lint_pass that analyses use of GC-managed types to make sure they’re "rooted" correctly. It traverses expressions HIR expression inside functions and methods, and requires access to the resolved type of these expressions as well as attributes on the definitions of these types. (Looking for custom attributes that indicate which types must be rooted. These attributes also need to be allowed by the compiler.)
Could this kind of analysis be built on top of RLS? Could that be a way forward for custom lints without relying on unstable rustc internals?
For the ast-level things, isn't proc_macros enough? Just execute a proc_macro at the root module of the crate, parse everything, do whatever transform you want to the code, and put them back together as a TokenStream.
For the ast-level things, isn't proc_macros enough? Just execute a proc_macro at the root module of the crate, parse everything, do whatever transform you want to the code, and put them back together as a TokenStream.
If we could do #![macro_invocations] that wraps around the whole file, this would be much easier
Just execute a proc_macro at the root module of the crate, parse everything
Does that entail tagging every function with a macro ? This project is meant to simplify the analysis of large scientific codebases. The plugin approach removes the need to dig into every twisted codebase, instead just compiling with a secret spice mix plugin to get instrumentation.
I find that creating a way to use custom inner macros would solve the problem. And if the plugin system is meant to simplify the analysis of large scientific codebases, there should be an alternative. Like custom inner attributes that are applied to every item.
Note that you can already replace rustc with your own by using the RUSTC_WRAPPER env var. This allows you to do your own preprocessing of the file and feed the output of that to the actual rustc. (Keyword "custom driver" if you want to search for ways to still access rustc internals like clippy and miri do)
The existing plugin API has not been maintained in years.
Activity
aturon commentedon Nov 5, 2015
Current status: awaiting a complete revamp of the plugin system.
cc @nrc
[-]Tracking issue for `plugin_registrar`[/-][+]Tracking issue for plugin stabilization (`plugin`, `plugin_registrar` features)[/+]jimmycuadra commentedon Jan 7, 2016
Is anyone actively working on this? Curious what the status is since using Serde without the need for code generation with syntex on stable Rust is very high on my Rust wishlist. 😃
steveklabnik commentedon Jan 7, 2016
@nrc is
aturon commentedon Jan 7, 2016
In particular, check out the discussion here, which points to a bunch of blog posts by @nrc amongst other things. He plans to finish the blog series and post an RFC soon.
jimmycuadra commentedon Jan 8, 2016
Thanks Aaron—I had read a couple of the posts about the macro system but it didn't click that this was intended to replace compiler plugins for the purpose of syntax extensions. It makes sense now, and looks great. I can't wait. :}
Add serde_codegen and build script for stable Rust
Add serde_codegen and build script for stable Rust
knight42 commentedon Aug 23, 2016
Any progress now?
SimonSapin commentedon Aug 23, 2016
Yes! The "Macros 1.1" RFC at rust-lang/rfcs#1681 was accepted. It’s implementation is tracked at #35900.
stop using a couple unstable features
SimonSapin commentedon Oct 13, 2017
The one remaining plugin in Servo is a
register_late_lint_passthat analyses use of GC-managed types to make sure they’re "rooted" correctly. It traverses expressions HIR expression inside functions and methods, and requires access to the resolved type of these expressions as well as attributes on the definitions of these types. (Looking for custom attributes that indicate which types must be rooted. These attributes also need to be allowed by the compiler.)Could this kind of analysis be built on top of RLS? Could that be a way forward for custom lints without relying on unstable rustc internals?
49 remaining items
crlf0710 commentedon Jan 11, 2023
For the ast-level things, isn't proc_macros enough? Just execute a proc_macro at the root module of the crate, parse everything, do whatever transform you want to the code, and put them back together as a
TokenStream.dlight commentedon Jan 11, 2023
If we could do
#![macro_invocations]that wraps around the whole file, this would be much easierspoutn1k commentedon Jan 11, 2023
Does that entail tagging every function with a macro ? This project is meant to simplify the analysis of large scientific codebases. The plugin approach removes the need to dig into every twisted codebase, instead just compiling with a secret spice mix plugin to get instrumentation.
blyxyas commentedon Jan 13, 2023
I find that creating a way to use custom inner macros would solve the problem. And if the plugin system is meant to simplify the analysis of large scientific codebases, there should be an alternative. Like custom inner attributes that are applied to every item.
oli-obk commentedon Jan 13, 2023
Note that you can already replace rustc with your own by using the
RUSTC_WRAPPERenv var. This allows you to do your own preprocessing of the file and feed the output of that to the actual rustc. (Keyword "custom driver" if you want to search for ways to still access rustc internals like clippy and miri do)The existing plugin API has not been maintained in years.
Remove support for compiler plugins.
Remove support for compiler plugins.
Remove support for compiler plugins.
Auto merge of rust-lang#116412 - nnethercote:rm-plugin-support, r=<try>
Remove support for compiler plugins.
Remove support for compiler plugins.
Auto merge of rust-lang#116412 - nnethercote:rm-plugin-support, r=bjorn3
Remove support for compiler plugins.
Remove support for compiler plugins.