Stream: t-compiler/help

Topic: Declarative macro 2.0 lowering issue

marmeladema (May 02 2020 at 23:18, on Zulip):

Hello everyone! I am trying to investigate an issue that I reported
And _i think_ that declarative macro 2.0 in closure are not lowered to hir properly. Looking at the test case, i end up in a situation where the def id does not have a corresponding hir id

marmeladema (May 02 2020 at 23:18, on Zulip):

Does that seem sensible?

marmeladema (May 03 2020 at 00:27, on Zulip):

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

marmeladema (May 03 2020 at 00:33, on Zulip):

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

marmeladema (May 03 2020 at 01:26, on Zulip):

I filled a bug for this in case I forget:

marmeladema (May 03 2020 at 19:04, on Zulip):

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

marmeladema (May 03 2020 at 19:30, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 12:53, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 12:53, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 12:54, on Zulip):

Macro items should then behave identically.

Vadim Petrochenkov (May 04 2020 at 12:56, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 12:57, on Zulip):

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.

Vadim Petrochenkov (May 04 2020 at 12:58, on Zulip):

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.

marmeladema (May 04 2020 at 17:49, on Zulip):

@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)

Vadim Petrochenkov (May 04 2020 at 17:53, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 17:54, on Zulip):

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

marmeladema (May 04 2020 at 17:58, on Zulip):

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

marmeladema (May 04 2020 at 22:04, on Zulip):

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

marmeladema (May 04 2020 at 23:15, on Zulip):

Is this really supposed to be working: ??

marmeladema (May 04 2020 at 23:15, on Zulip):

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

Vadim Petrochenkov (May 04 2020 at 23:44, on Zulip):

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.

Vadim Petrochenkov (May 04 2020 at 23:45, on Zulip):

Compatibility with macros 1.0.

marmeladema (May 04 2020 at 23:47, on Zulip):


marmeladema (May 04 2020 at 23:48, on Zulip):

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

marmeladema (May 04 2020 at 23:50, on Zulip):

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

Last update: Jan 22 2021 at 13:00UTC