Add `#[use_export]` attribute

[sam0x17]

So right now export_tokens already can take an ident to be used as a disambiguation name (needed for Items that don't have an inherent ident, or (previously) items that would otherwise collide with another item name-wise at the crate level). Now that we don't have to deal with crate-wide collisions, I think it would be reasonable to re-purpose this so that the ident you specify becomes the real name of the item.

The problem with doing this, though, is that then from the perspective of import_tokens_attr and import_tokens_proc we have no way of knowing which kind it is, one with a fake name or one with a real ident, and currently in Rust there is no way to be like "does this symbol exist? if not do this".

Now all of that said, let's pretend for a moment that we don't have to worry about names colliding with the item we are attaching #[export_tokens] to. If that were the case, then we could have #[export_tokens] emit something like this:

#[export_tokens]
struct MyStruct {
    field: usize,
}

=>

mod MyStruct {
    macro_rules! __export_tokens_tt_my_struct_0 {
        // ...
    }
}

Then we would be able to do an import like use my::crate::MyItem and MyItem::__export_tokens_tt_my_item_0 would work without issue.

The problem of course with this approach is the name collides with the original item, so it would only work with the no_emit version of #[export_tokens].

So at the end of the day I agree that the best we can do right now until rust adds the ability to ask if a symbol is defined at the current compilation step is to write some sort of #[use_export] macro

The problem with writing such a macro, though, is we will have to know the COUNTER for that particular export_tokens ident...

So it could be that we require specifying an ident like #[export_tokens(MyIdent)] for #[export_tokens] attributes that we want to be able to use with #[use_export], since for those we won't have the COUNTER problem because they will have an explicit name.

Yeah I think that is the solution. The unfortunate thing is I don't think there is a way to get an intelligent compile-error here pushing people towards adding an ident to their #[export_tokens] other than the built in error which is just going to say "type my::crate::MyItem is a type not an expression" or something like that.

Originally posted by @sam0x17 in https://github.com/paritytech/substrate/issues/14356#issuecomment-1591000962