|
8 | 8 | // option. This file may not be copied, modified, or distributed
|
9 | 9 | // except according to those terms.
|
10 | 10 |
|
11 |
| -// Lowers the AST to the HIR. |
12 |
| -// |
13 |
| -// Since the AST and HIR are fairly similar, this is mostly a simple procedure, |
14 |
| -// much like a fold. Where lowering involves a bit more work things get more |
15 |
| -// interesting and there are some invariants you should know about. These mostly |
16 |
| -// concern spans and ids. |
17 |
| -// |
18 |
| -// Spans are assigned to AST nodes during parsing and then are modified during |
19 |
| -// expansion to indicate the origin of a node and the process it went through |
20 |
| -// being expanded. Ids are assigned to AST nodes just before lowering. |
21 |
| -// |
22 |
| -// For the simpler lowering steps, ids and spans should be preserved. Unlike |
23 |
| -// expansion we do not preserve the process of lowering in the spans, so spans |
24 |
| -// should not be modified here. When creating a new node (as opposed to |
25 |
| -// 'folding' an existing one), then you create a new id using `next_id()`. |
26 |
| -// |
27 |
| -// You must ensure that ids are unique. That means that you should only use the |
28 |
| -// id from an AST node in a single HIR node (you can assume that AST node ids |
29 |
| -// are unique). Every new node must have a unique id. Avoid cloning HIR nodes. |
30 |
| -// If you do, you must then set the new node's id to a fresh one. |
31 |
| -// |
32 |
| -// Spans are used for error messages and for tools to map semantics back to |
33 |
| -// source code. It is therefore not as important with spans as ids to be strict |
34 |
| -// about use (you can't break the compiler by screwing up a span). Obviously, a |
35 |
| -// HIR node can only have a single span. But multiple nodes can have the same |
36 |
| -// span and spans don't need to be kept in order, etc. Where code is preserved |
37 |
| -// by lowering, it should have the same span as in the AST. Where HIR nodes are |
38 |
| -// new it is probably best to give a span for the whole AST node being lowered. |
39 |
| -// All nodes should have real spans, don't use dummy spans. Tools are likely to |
40 |
| -// get confused if the spans from leaf AST nodes occur in multiple places |
41 |
| -// in the HIR, especially for multiple identifiers. |
| 11 | +//! Lowers the AST to the HIR. |
| 12 | +//! |
| 13 | +//! Since the AST and HIR are fairly similar, this is mostly a simple procedure, |
| 14 | +//! much like a fold. Where lowering involves a bit more work things get more |
| 15 | +//! interesting and there are some invariants you should know about. These mostly |
| 16 | +//! concern spans and ids. |
| 17 | +//! |
| 18 | +//! Spans are assigned to AST nodes during parsing and then are modified during |
| 19 | +//! expansion to indicate the origin of a node and the process it went through |
| 20 | +//! being expanded. Ids are assigned to AST nodes just before lowering. |
| 21 | +//! |
| 22 | +//! For the simpler lowering steps, ids and spans should be preserved. Unlike |
| 23 | +//! expansion we do not preserve the process of lowering in the spans, so spans |
| 24 | +//! should not be modified here. When creating a new node (as opposed to |
| 25 | +//! 'folding' an existing one), then you create a new id using `next_id()`. |
| 26 | +//! |
| 27 | +//! You must ensure that ids are unique. That means that you should only use the |
| 28 | +//! id from an AST node in a single HIR node (you can assume that AST node ids |
| 29 | +//! are unique). Every new node must have a unique id. Avoid cloning HIR nodes. |
| 30 | +//! If you do, you must then set the new node's id to a fresh one. |
| 31 | +//! |
| 32 | +//! Spans are used for error messages and for tools to map semantics back to |
| 33 | +//! source code. It is therefore not as important with spans as ids to be strict |
| 34 | +//! about use (you can't break the compiler by screwing up a span). Obviously, a |
| 35 | +//! HIR node can only have a single span. But multiple nodes can have the same |
| 36 | +//! span and spans don't need to be kept in order, etc. Where code is preserved |
| 37 | +//! by lowering, it should have the same span as in the AST. Where HIR nodes are |
| 38 | +//! new it is probably best to give a span for the whole AST node being lowered. |
| 39 | +//! All nodes should have real spans, don't use dummy spans. Tools are likely to |
| 40 | +//! get confused if the spans from leaf AST nodes occur in multiple places |
| 41 | +//! in the HIR, especially for multiple identifiers. |
42 | 42 |
|
43 | 43 | use hir;
|
44 | 44 | use hir::map::{Definitions, DefKey, REGULAR_SPACE};
|
@@ -70,8 +70,10 @@ const HIR_ID_COUNTER_LOCKED: u32 = 0xFFFFFFFF;
|
70 | 70 |
|
71 | 71 | pub struct LoweringContext<'a> {
|
72 | 72 | crate_root: Option<&'static str>,
|
| 73 | + |
73 | 74 | // Use to assign ids to hir nodes that do not directly correspond to an ast node
|
74 | 75 | sess: &'a Session,
|
| 76 | + |
75 | 77 | // As we walk the AST we must keep track of the current 'parent' def id (in
|
76 | 78 | // the form of a DefIndex) so that if we create a new node which introduces
|
77 | 79 | // a definition, then we can properly create the def id.
|
@@ -102,14 +104,14 @@ pub struct LoweringContext<'a> {
|
102 | 104 | }
|
103 | 105 |
|
104 | 106 | pub trait Resolver {
|
105 |
| - // Resolve a hir path generated by the lowerer when expanding `for`, `if let`, etc. |
| 107 | + /// Resolve a hir path generated by the lowerer when expanding `for`, `if let`, etc. |
106 | 108 | fn resolve_hir_path(&mut self, path: &mut hir::Path, is_value: bool);
|
107 | 109 |
|
108 |
| - // Obtain the resolution for a node id |
| 110 | + /// Obtain the resolution for a node id |
109 | 111 | fn get_resolution(&mut self, id: NodeId) -> Option<PathResolution>;
|
110 | 112 |
|
111 |
| - // We must keep the set of definitions up to date as we add nodes that weren't in the AST. |
112 |
| - // This should only return `None` during testing. |
| 113 | + /// We must keep the set of definitions up to date as we add nodes that weren't in the AST. |
| 114 | + /// This should only return `None` during testing. |
113 | 115 | fn definitions(&mut self) -> &mut Definitions;
|
114 | 116 | }
|
115 | 117 |
|
|
0 commit comments