Skip to content
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

Closed
kmcallister opened this issue Jan 12, 2015 · 8 comments · Fixed by #22026
Closed

Stop using extern crate for plugins #21043

kmcallister opened this issue Jan 12, 2015 · 8 comments · Fixed by #22026
Assignees
Labels
A-plugin Area: compiler plugins, doc.rust-lang.org/nightly/unstable-book/language-features/plugin.html

Comments

@kmcallister
Copy link
Contributor

Then we can skip linking the library and it won't be confusing. Perhaps

#[plugin(...any metas...)] extern crate "my-lib" as foo;

would become

plugin!("my-lib" ...any TTs...);

There's no need for as foo because the library is not linked into the crate at all. The common case is just

plugin!(regex_macros);

when 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.

@kmcallister kmcallister added the A-plugin Area: compiler plugins, doc.rust-lang.org/nightly/unstable-book/language-features/plugin.html label Jan 12, 2015
@kmcallister kmcallister self-assigned this Jan 12, 2015
@kmcallister
Copy link
Contributor Author

plugin! would only be valid at module scope in the crate root.

@sfackler
Copy link
Member

We could probably make plugin! a syntax extension itself by extending the API to allow extensions to load new extensions (inception!).

@XMPPwocky
Copy link
Contributor

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?

@sfackler
Copy link
Member

@XMPPwocky the idea for plugin! is that #[no_link] will no longer be a thing at all. extern crate's currently overloaded to mean both "make the contents of this crate available to my program" and "load this into the compiler as a plugin".

@kmcallister
Copy link
Contributor Author

Are macros not expanded until after plugins run?

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.

@nagisa
Copy link
Member

nagisa commented Jan 12, 2015

#![plugin="regex_macros"] instead. Fits with -Z plugin=regex_macros or something better.

@kmcallister
Copy link
Contributor Author

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 #![feature] enabling built-in experimental features and #![plugin] loading new ones. Perhaps the syntax should be

#![plugin(regex_macros, foobar(...any metas...))]

which (like #![feature]) could also be split up as

#![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.

@daboross
Copy link
Contributor

I think the #![plugin] syntax might be a bit confusing due to the fact plugins still need to be added as cargo dependencies as well.

kmcallister added a commit to kmcallister/rust that referenced this issue Feb 9, 2015
    #[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]
bors added a commit that referenced this issue Feb 10, 2015
```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]
bors added a commit that referenced this issue Feb 10, 2015
```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]
dlrobertson pushed a commit to dlrobertson/rust that referenced this issue Nov 29, 2018
    #[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]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-plugin Area: compiler plugins, doc.rust-lang.org/nightly/unstable-book/language-features/plugin.html
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants