Hello everyone! I am trying to investigate an issue that I reported https://github.com/rust-lang/rust/issues/71104
And _i think_ that declarative macro 2.0 in closure are not lowered to hir properly. Looking at the https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/macro-in-closure.rs test case, i end up in a situation where the def id does not have a corresponding hir id

Does that seem sensible?

so the bug is triggered because the declarative macro is appended to the exported_macros vec and later on rustdoc tries to access the parent def id of the macro, which is not properly lowered because its a closure

should a declarative macro be exported when defined in a closure?

I filled a bug for this in case I forget: https://github.com/rust-lang/rust/issues/71820

I'd like to fix this issue to understand the internals of the compiler, would someone be ready to mentor me? I have a few questions

@Vadim Petrochenkov if you have some time :) its about lowering of declararive macro

Not sure about the details, but my first question here is what happens with non-macro items?

(Non-macro items if they are defined in a closure.)

Macro items should then behave identically.

In general, I'm not sure why macros are lowered into a separate list in HIR.

Perhaps then need to be lowered into regular HIR items since they need to exist until metadata encoding and metadata encoding is performed on HIR.

Anyway, doing that is probably not necessary for resolving the issue with IDs, it's likely that macros can do same things with IDs like other items while still being stored in a separate list.

@Vadim Petrochenkov ok ill try to understand how it works for other items. On the same topic, i see that now declarative macros have a visibility token associated pub/pub(crate)/etc. Should a macro without pub/pub(crate) inside a closure be exported (ie: made public)

Same logic "macro items should behave like other items" applies here.

We encode all items, even private ones.
They are used in diagnostics, at the very least.

I checked for regular macro rules, and if the macro_export attribute is not present, they are not part of the hir tree

I managed to reproduce it using regular macro rules so i guess its a more generic issue

Is this really supposed to be working: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b0a0cf8828275c5be13a89d96df1b19b ??

#[macro_export] exposes the macro to the whole current module/crate? No matter where the macro is defined?

Yep, that's how it works.
#[macro_export] plants the macro into the crate root, so it's available as that_crate::mac to other crates and as crate::mac to this crate.

Compatibility with macros 1.0.

Ok

and in term of hir, i tried to understand how other thing works when within a closure but macros are kind of the only thing that can be defined inside a closure and be visible outside

so i don't know how in that case they should be lowered, basically i don't know if 1/ the closure should be lowered differently or 2/ the exported macros should belong to the module directly