-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Support #[macro_reexport]
ing custom derives
#37542
Conversation
bf9164a
to
596a773
Compare
cc #35896 #35900 |
ae64f33
to
39b65bd
Compare
Nice! |
39b65bd
to
7012100
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not clear on what is going on here - why do we want macro_reexport and custom derive to work together? I would like macro_reexport to disappear entirely and I don't know of any motivation for it to work with custom derive. I assume this is a step towards something else, but I'm not sure what
extern crate derive_a; | ||
//~^ ERROR: crates of the `proc-macro` crate type cannot be linked at runtime | ||
|
||
fn main() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test should still be valid, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a good reason to disallow it? For example, we will want to support:
extern crate derive_a;
use derive_a::A;
#[derive(A)] struct Foo;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to maintain a strict phase distinction between macro and non-macro crates (we intend to relax this eventually, but I don't want it to creep in). I don't want the macro_use to be optional, and until we actually support use
ing derives, it seems that we should require it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still a phase distinction -- only the macros are available from extern crate derive_a
and derive_a
is not linked.
until we actually support
use
ing derives
I was going to support this behind a feature gate in a PR tomorrow...
I don't want the macro_use to be optional
Why not? Without #[macro_use]
or the ability to use
derives, extern crate derive_a;
just defines an empty module derive_a
. Maybe a warning would be appropriate, but I don't see a reason to disallow it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, if use
ing derives will work soon, then lets allow it. As long as the non-macro_use case has sensible semantics, then I see no reason to block it.
@@ -15,6 +15,6 @@ | |||
#[macro_use] | |||
extern crate derive_a; | |||
#[macro_use] | |||
extern crate derive_a; //~ ERROR `derive_a` has already been defined | |||
extern crate derive_a; //~ ERROR `derive_a` has already been imported | |||
|
|||
fn main() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a test that uses macro_reexport with a custom derive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I added a test.
let def = self.cx.sess().cstore.load_macro(def_id, self.cx.sess()); | ||
let def = match self.cx.sess().cstore.load_macro(def_id, self.cx.sess()) { | ||
LoadedMacro::MacroRules(macro_rules) => macro_rules, | ||
LoadedMacro::ProcMacro(..) => continue, // FIXME |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This FIXME needs more explanation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@nrc The main purpose of this PR is to change the metadata to support reexporting custom derives.
|
OK, that makes sense. |
☔ The latest upstream changes (presumably #37506) made this pull request unmergeable. Please resolve the merge conflicts. |
e4d0070
to
652ec19
Compare
r = me, but a test seems to be broken |
652ec19
to
8d44bd5
Compare
@bors r=nrc |
📌 Commit 8d44bd5 has been approved by |
⌛ Testing commit 8d44bd5 with merge 9723bd2... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
8d44bd5
to
5173173
Compare
@bors r=nrc |
📌 Commit 5173173 has been approved by |
🔒 Merge conflict |
☔ The latest upstream changes (presumably #37670) made this pull request unmergeable. Please resolve the merge conflicts. |
that is referenced by multiple `extern crate` items.
c5d28e8
to
76d15f4
Compare
76d15f4
to
f35eff2
Compare
@bors r=nrc |
📌 Commit f35eff2 has been approved by |
Support `#[macro_reexport]`ing custom derives This is gated behind `#![feature(macro_reexport)]` and `#![feature(proc_macro)]`. r? @nrc
This is gated behind
#![feature(macro_reexport)]
and#![feature(proc_macro)]
.r? @nrc