Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

m! macro does not work with new ( 1.30.0 ) stable rusts #[macro_export(local_inner_macros)] #16

Closed
softprops opened this issue Oct 26, 2018 · 8 comments

Comments

@softprops
Copy link
Contributor

softprops commented Oct 26, 2018

a new feature stabilized in rust ( release notes here ) that allows macro authors to have rust "re-export" macros they depend on. I use my own macros which depend on mashup! and have tested this feature but it seems ( at least in doc tests ) that rust is not able to resolve the m! macro potentially because this is edgecasey and maybe not supported as I think mashup is a macro that produces a macro.

I'm not sure if its a bug or a feature yet but I wanted to get it on your radar.

@dtolnay
Copy link
Owner

dtolnay commented Oct 26, 2018

Thanks, I would accept a PR to make mashup work with new style macro imports.

@softprops
Copy link
Contributor Author

I'm a little fuzzy on proc_macro_hack and proc_macro2 and if they are even needed anymore but I'm getting stuck on what scope to fit the exported substitution ( ex m! ) macros into. I tried both mashup:: and $crate:: and the neither puts it in the appropriate scope for use.

@softprops
Copy link
Contributor Author

It looks like proc macro2 was a shim to get what was released in 1.30 working on stable before it was stable https://github.com/alexcrichton/proc-macro2/blob/master/README.md. does that mean this crate no longer needs it?

@softprops
Copy link
Contributor Author

@dtolnay I was going to try to take another take on this this week. Let me know if you can provide any context on the questions above. That may help save some time.

@softprops
Copy link
Contributor Author

I'm going to start an separate experiment to see if I can get away from the proc_macro2 dependency

@softprops
Copy link
Contributor Author

I learned after see travis errors in the proc_macro proper pull that this repo is set up to support older versions which would prevents the use of using the provided stable proc_macro api but also would prevent the use of the now stable interface removing the need for #[macro_use] in this gh issue.

Thoughts on removing support for older versions @dtolnay ?

@softprops
Copy link
Contributor Author

I also just noticed the no_raw_identifiers cfg settings. These are also now stabilized in 1.30.0

@softprops softprops mentioned this issue Oct 30, 2018
5 tasks
@dtolnay
Copy link
Owner

dtolnay commented Apr 4, 2020

Closing because I don't plan to take a fix for this, people targeting newer toolchains should be using https://github.com/dtolnay/paste.

@dtolnay dtolnay closed this as completed Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants