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
Stop using extern crate
for plugins
#21043
Comments
|
We could probably make |
Why can't plugin! be a simple macro that expands to #[no_link] #[plugin] extern crate $name; ? Are macros not expanded until after plugins run? |
@XMPPwocky the idea for |
Correct. Plugin loading, plugin registration, and syntax expansion happen in distinct stages. This is needed due to the libsyntax / librustc split, and seems like a clean design generally. But it does entail collecting plugins to load before we've done any macro expansion at all. |
|
They they have to go at the top of your crate root file, but that seems acceptable and maybe even beneficial. There's a sort of analogy with #![plugin(regex_macros, foobar(...any metas...))] which (like #![plugin(regex_macros)]
#![plugin(foobar(...any metas...))] It's less clear how to deal with crate names that aren't valid identifiers, but I'm fine simply disallowing that for plugins, at least in the short term. |
I think the |
#[plugin] #[no_link] extern crate bleh; becomes a crate attribute #![plugin(bleh)] The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes rust-lang#21043. Fixes rust-lang#20769. [breaking-change]
```rust #[plugin] #[no_link] extern crate bleh; ``` becomes a crate attribute ```rust #![plugin(bleh)] ``` The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes #21043. Fixes #20769. [breaking-change]
```rust #[plugin] #[no_link] extern crate bleh; ``` becomes a crate attribute ```rust #![plugin(bleh)] ``` The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes #21043. Fixes #20769. [breaking-change]
#[plugin] #[no_link] extern crate bleh; becomes a crate attribute #![plugin(bleh)] The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes rust-lang#21043. Fixes rust-lang#20769. [breaking-change]
Then we can skip linking the library and it won't be confusing. Perhaps
would become
There's no need for
as foo
because the library is not linked into the crate at all. The common case is justwhen the crate name is a valid identifier and there are no arguments.
This entails making the name
plugin!
special to the macro expander, since we need to locate plugins before we can load them.The text was updated successfully, but these errors were encountered: