Tracking issue for plugin stabilization (`plugin`, `plugin_registrar` features)

[aturon]

Tracks stabilization for the plugin and plugin_registrar feature gates.

[aturon]

Current status: awaiting a complete revamp of the plugin system.

cc @nrc

[nixpulvis]

How do (or might) plugins affect saftey guarantees of the language?

[jimmycuadra]

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]

@nrc is

[aturon]

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]

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. :}

[knight42]

Any progress now?

[SimonSapin]

Yes! The "Macros 1.1" RFC at rust-lang/rfcs#1681 was accepted. It’s implementation is tracked at #35900.

[SimonSapin]

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?

[eisterman]

Any progress now?

[0rvar]

Are there any plans for stabilizing plugins in the foreseeable future?

[oli-obk]

The plan is to remove the plugin API entirely.

[vityafx]

@oli-obk Could you go into details please?

[oli-obk]

Even if we stabilized the plugin interface, it would be useless, because there is no stable API it offers. Instead things like proc macros 2.0, custom derive, ... are stabilized by offering an interface that does not require the language to guarantee a plugin interface to the compiler. All of these non-plugin-requiring APIs can be implemented with various other schemes, even if they are currently implemented via plugins in the background.

Note: this issue is not about allowing writing bin crates which can be extended via plugins, it is about plugins that can extend the compiler.

[vityafx]

Is not rocket a plugin to a compiler? If so, that means we will bury it alive?

[oli-obk]

Rocket is a plugin to the compiler because proc macros 2.0, and most notably their attribute support is not implemented yet. Of course there is no desire to eliminate any uses of the plugin API without a viable alternative. But there is also no desire to stabilize it while there are much better alternatives on the horizon. Especially if stabilizing has a high cost for the compiler, while the alternatives do not have the same cost associated with them.