Stop using `extern crate` for plugins

[kmcallister]

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]

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

[sfackler]

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

[XMPPwocky]

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]

@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]

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]

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

[kmcallister]

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]

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.