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

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

Open
aturon opened this Issue Nov 5, 2015 · 16 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Nov 5, 2015

Tracks stabilization for the plugin and plugin_registrar feature gates.

@aturon

This comment has been minimized.

Member

aturon commented Nov 5, 2015

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

cc @nrc

@nixpulvis

This comment has been minimized.

nixpulvis commented Nov 5, 2015

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

@aturon aturon changed the title from Tracking issue for `plugin_registrar` to Tracking issue for plugin stabilization (`plugin`, `plugin_registrar` features) Nov 5, 2015

@jimmycuadra

This comment has been minimized.

Contributor

jimmycuadra commented 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

This comment has been minimized.

Member

steveklabnik commented Jan 7, 2016

@nrc is

@aturon

This comment has been minimized.

Member

aturon commented 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

This comment has been minimized.

Contributor

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

callahad added a commit to callahad/ladaemon that referenced this issue Jun 24, 2016

Add serde_codegen and build script for stable Rust
This is necessary because stable Rust does not yet support custom #[derive]
implementations, which are needed for Serde's Serialize/Deserialize traits.

Serde has a macro package and compiler plugin which handle those, but compiler
plugins are *also* not availble in stable Rust, so we instead have to generate
code at build time using serde_codegen.

Bug for `custom_derive` feature: rust-lang/rust#29644

Bug for compiler plugins: rust-lang/rust#29597

callahad added a commit to callahad/ladaemon that referenced this issue Jun 26, 2016

Add serde_codegen and build script for stable Rust
This is necessary because stable Rust does not yet support custom #[derive]
implementations, which are needed for Serde's Serialize/Deserialize traits.

Serde has a macro package and compiler plugin which handle those, but compiler
plugins are *also* not availble in stable Rust, so we instead have to generate
code at build time using serde_codegen.

Bug for `custom_derive` feature: rust-lang/rust#29644

Bug for compiler plugins: rust-lang/rust#29597
@knight42

This comment has been minimized.

Contributor

knight42 commented Aug 23, 2016

Any progress now?

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Aug 23, 2016

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

@knight42 knight42 referenced this issue Aug 23, 2016

Open

[WIP] tests: simplified declarations #981

0 of 1 task complete

scottlamb added a commit to scottlamb/moonfire-nvr that referenced this issue Dec 8, 2016

stop using a couple unstable features
It would be nice to build on stable Rust. In particular, I'm hitting
compiler bugs in Rust nightly, such at this one:
rust-lang/rust#38177
I imagine beta/stable compilers would be less problematic.

These two features were easy to get rid of:

* alloc was used to get a Box<[u8]> to uninitialized memory.
  Looks like that's possible with Vec.

* box_syntax wasn't actually used at all. (Maybe a leftover from something.)

The remaining features are:

* plugin, for clippy.
  rust-lang/rust#29597
  I could easily gate it with a "nightly" cargo feature.

* proc_macro, for serde_derive.
  rust-lang/rust#35900
  serde does support stable rust, although it's annoying.
  https://serde.rs/codegen-stable.html
  I might just wait a bit; this feature looks like it's getting close to
  stabilization.

@SimonSapin SimonSapin referenced this issue Feb 19, 2017

Open

Tracking issue for 1.0.0 tracking issues #39954

9 of 28 tasks complete
@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Oct 13, 2017

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

This comment has been minimized.

eisterman commented Mar 31, 2018

Any progress now?

@0rvar

This comment has been minimized.

0rvar commented Jul 16, 2018

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

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Jul 16, 2018

The plan is to remove the plugin API entirely.

@vityafx

This comment has been minimized.

vityafx commented Aug 3, 2018

@oli-obk Could you go into details please?

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Aug 3, 2018

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

This comment has been minimized.

vityafx commented Aug 3, 2018

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

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Aug 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment