- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
          Support #[macro_reexport]ing custom derives
          #37542
        
          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
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
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 useing 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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
        
          
                src/librustdoc/visit_ast.rs
              
                Outdated
          
        
      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  | 
| ⌛ 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