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

Macro reexporting broken in 0.1.24 & 0.1.25 #241

Closed
bearcage opened this issue Oct 19, 2022 · 9 comments
Closed

Macro reexporting broken in 0.1.24 & 0.1.25 #241

bearcage opened this issue Oct 19, 2022 · 9 comments

Comments

@bearcage
Copy link
Contributor

The changes from this diff and released in 0.1.24 and the subsequent 0.1.25 (which, incidentally, looks to be available on crates.io but not reflected in the commit history pushed to github for ctor/Cargo.toml) refer to ctor as a top level module in the macro callsites which deduplicated the big cfg_attr blocks. This, unfortunately, results in errors that look like the attached screenshot if you have reexported the ctor attribute macro in a crate of your own.

Specifically, this happens because crates which depend on ctor by another name, or only transitively (as in my use case) will not have ::ctor available. The usual workaround for this of reexporting dependency macros from your own crate (::config::premain_support::ctor in my case) doesn't work if the reexported macro generates references to itself by name. For not-so-procedural macros, $crate is available to work around this. There might be a general answer for this for procedural macros, but I'm not aware of one -- I'll take a quick look and see what I can find, though.

image

@bearcage bearcage changed the title Macro reexporting broken in 0.1.25 Macro reexporting broken in 0.1.24 & 0.1.25 Oct 19, 2022
@bearcage
Copy link
Contributor Author

bearcage commented Oct 19, 2022

Looks like this can be done with proc macros, as of 2019 (last time I looked was a good while before that)! The extern_crate_self feature, which afaict stabilized in 1.34, allows a local rename of self in the crate that defines the macro -- intended to fix just this problem.

@mmastrac
Copy link
Owner

@bearcage Damn, thanks for this catch. Let me see what I can do.

@bearcage
Copy link
Contributor Author

No sweat -- PR incoming!

@bearcage
Copy link
Contributor Author

or it will be if I can sort out how exactly that feature's meant to work anyhow

@mmastrac
Copy link
Owner

@bearcage Excellent. If you get it, let me know.

The alternative is that we can just pass the whole cfg_attr array into quote!.

@bearcage
Copy link
Contributor Author

Ok, as far as I can tell that feature unfortunately seems to only work for referring to not-macro things out of self since macro_use isn't supported for extern crate self. On the bright side, doing what you said and expanding the whole cfg_attr set in the quote doesn't bump the minimum rust version either, so I'll do that and send a PR your way.

@mmastrac
Copy link
Owner

mmastrac commented Oct 19, 2022

@bearcage I pulled a bit of a quick rework in 27656d9 - fingers crossed that fixes it.

@mmastrac
Copy link
Owner

mmastrac commented Oct 19, 2022

Fixed in 0.1.26 🤞 - I don't see why this solution would't work but please re-open if it doesn't! Thanks for the report.

@bearcage
Copy link
Contributor Author

That does the job for me, thanks much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants