Support #[macro_reexport]ing custom derives#37542
Conversation
bf9164a to
596a773
Compare
|
cc #35896 #35900 |
ae64f33 to
39b65bd
Compare
|
Nice! |
39b65bd to
7012100
Compare
nrc
left a comment
There was a problem hiding this comment.
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
There was a problem hiding this comment.
This test should still be valid, no?
There was a problem hiding this comment.
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.
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 useing derives, it seems that we should require it.
There was a problem hiding this comment.
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
useing 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.
OK, if useing 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.
There was a problem hiding this comment.
Should we have a test that uses macro_reexport with a custom derive?
There was a problem hiding this comment.
Yeah, I added a test.
src/librustdoc/visit_ast.rs
Outdated
|
@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 |
|
⌛ Testing commit f35eff2 with merge 187d989... |
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