1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
//! Stable handles identifying a module within a graph.
/// A small, copyable handle to one module in a [`ModuleGraph`](crate::ModuleGraph).
///
/// A `ModuleId` is a 32-bit index minted by the graph when a module is added with
/// [`ModuleGraph::add_module`](crate::ModuleGraph::add_module). It is stable for
/// the life of the graph: the id returned for a module keeps pointing at that same
/// module no matter how many more are added afterwards, because modules are only
/// ever appended. That stability is what lets an import edge, an AST node, or a
/// cached diagnostic hold a `ModuleId` and resolve it later.
///
/// The id is deliberately opaque — there is no public constructor — so an id can
/// only come from the graph that actually holds the module it names. Passing an id
/// minted by a *different* graph to a query is a defined error
/// ([`ResolveError::UnknownModule`](crate::ResolveError::UnknownModule)), never a
/// panic or an out-of-bounds read.
///
/// # Examples
///
/// ```
/// use intern_lang::Interner;
/// use module_lang::ModuleGraph;
/// use source_lang::SourceMap;
///
/// let mut sources = SourceMap::new();
/// let mut names = Interner::new();
/// let mut graph: ModuleGraph<()> = ModuleGraph::new();
///
/// let a = graph.add_module(names.intern("a"), sources.add("a", "").expect("fits"));
/// let b = graph.add_module(names.intern("b"), sources.add("b", "").expect("fits"));
///
/// // Ids are assigned in order and stay distinct.
/// assert_eq!(a.to_u32(), 0);
/// assert_eq!(b.to_u32(), 1);
/// assert_ne!(a, b);
/// ```
///
/// With the `serde` feature it serialises transparently as its `u32` index, so a
/// handle stored in an AST node or an import table round-trips on its own.
;