-
Notifications
You must be signed in to change notification settings - Fork 4
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
Revamp / v0.4 #3
Comments
This is fantastic! Love the solution of having the macro call itself in different situations. The original code for all of this was the product of a 3 week fever dream so it's great to see you got around the main problems I was unable to solve @thiolliere <3 |
I'll probably do a bump to 0.4.x when we release this btw |
regarding 3., this is also great. It never occurred to me that we can just pass an expr around and then later evaluate it when we do the final expansion. That would be a lot more flexible 👍🏻 |
for 3, I was wondering what would be the best API:
maybe best could be to have both so people can use what they want. |
Yeah this sounds good. I was thinking of something like the following, if this still has the same flexibility you are talking about (I think it does?): 1-arg expr#[import_tokens_attr(format!("{}::macro_magic", generate_crate_access_2018("frame-support")))] we would expect the expr to expand to an 1-arg path#[import_tokens_attr(frame_support::macro_magic)] This one would work essentially the way it does now Are there any problems with that? |
yes it looks good. |
Ok at this point items 1-3 have been merged and docs have been updated. I'm going to go ahead and release 0.4.0. May decide to do item 4 as well later. Thanks again for all your help @thiolliere! |
thanks for the great crate, I hope I was a little helpful. Yes 4 is not important and to be discussed maybe. |
(This issue make use of example from substrate, for people not familiar, please ask I will use genuine example.)
1 [x] remove need for
use_attr
use_attr
anduse_proc
#5in
import_tokens_attr_internal
, instead of generating 2 proc macrosorig_sig
andinner_sig
, we could generate onlyorig_sig
.here is how: if there is a special first token then
orig_sig
will do asinner_sig
. otherwise it does asorig_sig
currently except at the end if generates theforward_tokens
to call himself again but with a special first token.Having only one function allow to get rid of
use_attr
because there is no longer anyinner_sig
function to keep along.2 allow
export_tokens
to export the sameident
but at different pathin
export_tokens
instead of generating just a macro_rules we can do similar toframe::pallet
:we create a unique_name with just a global counter in the macro_magic proc crate:
and then we generate the macro_rule with the unique_id and then make a
use
statement to assign with the correct id in the scope of the definition only (instead of root scope).This is less important but it allows for instance many pallet in the same crate to register
TestDefaultConfig
for instance.Currently if 2 pallet in the same crate register the same
TestDefaultConfig
then there is a conflict.3 resolution of
mm_override_path
done dynamicallyInstead of having the path to macro_magic requested as hardcoded: e.g. in
#[import_tokens_attr(frame_support::macro_magic)]
we should be able to give a code that would give the path to macro_magic later when the proc_macroorig_sig
is called.It would look like this:
then in substrate we can write derive_impl attribute like this:
4 add a parameter to
import_tokens
to dynamically fetch the path toself
(e.g.DeriveImpl
) thus removing the need to always import the macro in scope and allow to callframe_support::DeriveImpl
directly.not very needed but we could also give into attribute the expression to resolve the path to
inner_macro_ident
so the call to forward_tokens would look like this:
so that derive_impl can tell that it is expected to be found in
frame-support
andframe
and so it doesn't need to be imported in scope.Thought the drawback is that it means
DeriveImpl
cannot be re-exported either because it is only expected inframe_support
andframe
. That said, consideringmacro_magic::forward_token
already require to give the path to be found at (e.g.frame
orframe-support
), the reexport is already impossible. (what I mean is thatderive_impl
already need to give an expression to fetch to path toforward_tokens
to if there is a reexport in crateFoo
caller ofderive_impl
will still need to depend on cratemacro_magic
orframe
orframe_support
)The text was updated successfully, but these errors were encountered: