@@ -48,45 +48,45 @@ iteration, this represents a compile error. Here is the [algorithm][original]:
4848[ fef ] : https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.MacroExpander.html#method.fully_expand_fragment
4949[ original ] : https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049
5050
51- 0 . Initialize an ` queue ` of unresolved macros.
52- 1 . Repeat until ` queue ` is empty (or we make no progress, which is an error):
53- 0 . [ Resolve] ( ./name-resolution.md ) imports in our partially built crate as
54- much as possible.
55- 1 . Collect as many macro [ ` Invocation ` s] [ inv ] as possible from our
56- partially built crate (fn-like, attributes, derives) and add them to the
57- queue.
58- 2 . Dequeue the first element, and attempt to resolve it.
59- 3 . If it's resolved:
60- 0 . Run the macro's expander function that consumes a [ ` TokenStream ` ] or
61- AST and produces a [ ` TokenStream ` ] or [ ` AstFragment ` ] (depending on
62- the macro kind). (A ` TokenStream ` is a collection of [ ` TokenTree ` s] [ tt ] ,
63- each of which are a token (punctuation, identifier, or literal) or a
64- delimited group (anything inside ` () ` /` [] ` /` {} ` )).
65- - At this point, we know everything about the macro itself and can
66- call ` set_expn_data ` to fill in its properties in the global data;
67- that is the hygiene data associated with ` ExpnId ` . (See [ the
68- "Hygiene" section below] [ hybelow ] ).
69- 1 . Integrate that piece of AST into the big existing partially built
70- AST. This is essentially where the "token-like mass" becomes a
71- proper set-in-stone AST with side-tables. It happens as follows:
72- - If the macro produces tokens (e.g. a proc macro), we parse into
73- an AST, which may produce parse errors.
74- - During expansion, we create ` SyntaxContext ` s (hierarchy 2). (See
75- [ the "Hygiene" section below] [ hybelow ] )
76- - These three passes happen one after another on every AST fragment
77- freshly expanded from a macro:
78- - [ ` NodeId ` ] s are assigned by [ ` InvocationCollector ` ] . This
79- also collects new macro calls from this new AST piece and
80- adds them to the queue.
81- - [ "Def paths"] [ defpath ] are created and [ ` DefId ` ] s are
82- assigned to them by [ ` DefCollector ` ] .
83- - Names are put into modules (from the resolver's point of
84- view) by [ ` BuildReducedGraphVisitor ` ] .
85- 2 . After expanding a single macro and integrating its output, continue
86- to the next iteration of [ ` fully_expand_fragment ` ] [ fef ] .
87- 4 . If it's not resolved:
88- 0 . Put the macro back in the queue
89- 1 . Continue to next iteration...
51+ 1 . Initialize an ` queue ` of unresolved macros.
52+ 2 . Repeat until ` queue ` is empty (or we make no progress, which is an error):
53+ 1 . [ Resolve] ( ./name-resolution.md ) imports in our partially built crate as
54+ much as possible.
55+ 2 . Collect as many macro [ ` Invocation ` s] [ inv ] as possible from our
56+ partially built crate (fn-like, attributes, derives) and add them to the
57+ queue.
58+ 3 . Dequeue the first element, and attempt to resolve it.
59+ 4 . If it's resolved:
60+ 1 . Run the macro's expander function that consumes a [ ` TokenStream ` ] or
61+ AST and produces a [ ` TokenStream ` ] or [ ` AstFragment ` ] (depending on
62+ the macro kind). (A ` TokenStream ` is a collection of [ ` TokenTree ` s] [ tt ] ,
63+ each of which are a token (punctuation, identifier, or literal) or a
64+ delimited group (anything inside ` () ` /` [] ` /` {} ` )).
65+ - At this point, we know everything about the macro itself and can
66+ call ` set_expn_data ` to fill in its properties in the global data;
67+ that is the hygiene data associated with ` ExpnId ` . (See [ the
68+ "Hygiene" section below] [ hybelow ] ).
69+ 2 . Integrate that piece of AST into the big existing partially built
70+ AST. This is essentially where the "token-like mass" becomes a
71+ proper set-in-stone AST with side-tables. It happens as follows:
72+ - If the macro produces tokens (e.g. a proc macro), we parse into
73+ an AST, which may produce parse errors.
74+ - During expansion, we create ` SyntaxContext ` s (hierarchy 2). (See
75+ [ the "Hygiene" section below] [ hybelow ] )
76+ - These three passes happen one after another on every AST fragment
77+ freshly expanded from a macro:
78+ - [ ` NodeId ` ] s are assigned by [ ` InvocationCollector ` ] . This
79+ also collects new macro calls from this new AST piece and
80+ adds them to the queue.
81+ - [ "Def paths"] [ defpath ] are created and [ ` DefId ` ] s are
82+ assigned to them by [ ` DefCollector ` ] .
83+ - Names are put into modules (from the resolver's point of
84+ view) by [ ` BuildReducedGraphVisitor ` ] .
85+ 3 . After expanding a single macro and integrating its output, continue
86+ to the next iteration of [ ` fully_expand_fragment ` ] [ fef ] .
87+ 5 . If it's not resolved:
88+ 1 . Put the macro back in the queue
89+ 2 . Continue to next iteration...
9090
9191[ defpath ] : hir.md#identifiers-in-the-hir
9292[ `NodeId` ] : https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html
0 commit comments