New export_tokens path strategy

[sam0x17]

This fulfills item 2 from #3

With this new strategy, we can now properly access #[export_tokens] declarations as real items within the modules in which they are defined, instead of faking it and accessing them from the #[macro_export] created at the crate root.

This is a breaking change since it is no longer possible (at least with how the macros are written currently) to do two things that used to be possible:

1. access #[export_tokens] declarations that are inside of things like functions that are not accessible at the module level
2. access #[export_tokens] declarations that are in private modules

I think this is largely OK if we have to drop support for this, but I would still like to brainstorm some possible workarounds so we can still make these work, possibly with some additional opt-in macro argument.

[sam0x17]

would love your thoughts on this if you have any @thiolliere

[gui1117]

This is a breaking change since it is no longer possible (at least with how the macros are written currently) to do two things that used to be possible:

1. access `#[export_tokens]` declarations that are _inside of_ things like functions that are not accessible at the module level

2. access `#[export_tokens]` declarations that are in private modules

I see now that it is limiting the features of export_tokens.
As you say we could still re-enable it with an attribute like [export_tokens(declare_at_crate_root)].

The main advantage of this PR implementation IMO is that path feels more natural and there is no conflict if 2 pallets declare the same reexport: TestDefaultConfig

But if we don't want that we can fix the issue paritytech/substrate#14287 by requiring in attribute the correct path which should points to the item at the crate root, and search for __export_tokens_tt_test_default_config at this path.
e.g. the call would look like this:

#[derive_impl(bar::frame_system::TestDefaultConfig as frame_system::DefaultConfig)]

instead of

#[derive_impl(bar::frame_system::config_preludes::TestDefaultConfig as frame_system::DefaultConfig)]

and then we search for the __export_tokens_tt_test_default_config at the path except last segment so: bar::frame_system

[gui1117]

Yes implementation is good to me 👍

[gui1117]

maybe this is slightly cleaner as we don't loose the path leading colon, what do you think?

Suggested change

	let Some(last_seg) = item_path.segments.last() else { unreachable!("must have at least one segment") };
	let mut leading_segs = item_path
	.segments
	.iter()
	.cloned()
	.map(|seg| seg.ident)
	.collect::<Vec<_>>()[0..item_path.segments.len() - 1]
	.to_vec();
	let last_seg = export_tokens_macro_ident(&last_seg.ident);
	leading_segs.push(last_seg);
	parse_quote!(#(#leading_segs)::*)
	let mut macro_path = item_path.clone();
	let Some(syn::punctuated::Pair::End(last_seg)) = macro_path.segments.pop()
	else { unreachable!("Path must have a last segment") };
	let last_seg = export_tokens_macro_ident(&last_seg.ident);
	macro_path.segments.push(last_seg.into());
	macro_path

[gui1117]

Thinking again, we could do 2 attribute macros: export_tokens and export_tokens_at_crate_root

[sam0x17]

Yes, am working on something like the 2 attribute approach you mentioned

[sam0x17]

Yeah upon further thought and investigation I think it is worth it to do a breaking change and drop this (accessing private items) feature for now. No one I have spoken to is using this, and to be fair, if someone has enough control over the code to add #[export_tokens], they also have enough control to make the module public. So I will merge this as is