You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/names/name-resolution.md
+31-30Lines changed: 31 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,70 +2,71 @@ r[names.resolution]
2
2
# Name resolution
3
3
4
4
r[names.resolution.intro]
5
-
_Name resolution_ is the process of tying paths and other identifiers to the declarations of those entities. Names are segregated into different [namespaces], allowing entities in different namespaces to share the same name without conflict. Each name is valid within a [scope], or a region of source text where that name may be referenced. Access to certain names may be restricted based on their[visibility].
5
+
_Name resolution_ is the process of tying paths and other identifiers to the declarations of those entities. Names are segregated into different [namespaces], allowing entities in different namespaces to share the same name without conflict. Each name is valid within a [scope], or a region of source text where that name may be referenced. Access to a name may be restricted based on its[visibility].
6
6
7
-
Name resolution is split into three stages throughout the compilation process. The first stage, *expansion-time resolution*, resolves all [`use` declarations] and [macro invocations]. The second stage, *primary resolution*, resolves all names that have not yet been resolved that do not depend on type information to resolve. The last stage, *type-relative resolution*, resolves the remaining names once type information is available.
7
+
Name resolution is split into three stages throughout the compilation process. The first stage, *expansion-time resolution*, resolves all [`use` declarations] and [macro invocations]. The second stage, *primary resolution*, resolves all names that have not yet been resolved and that do not depend on type information to resolve. The last stage, *type-relative resolution*, resolves the remaining names once type information is available.
8
8
9
9
> [!NOTE]
10
-
>
11
-
> * Expansion-time resolution is also known as "early resolution".
12
-
> * Primary resolution is also known as "late resolution".
10
+
> Expansion-time resolution is also known as *early resolution*. Primary resolution is also known as *late resolution*.
13
11
14
12
r[names.resolution.general]
15
13
## General
16
14
17
15
r[names.resolution.general.intro]
18
-
The following rules apply to all stages of name resolution.
16
+
The rules within this section apply to all stages of name resolution.
19
17
20
18
r[names.resolution.general.scopes]
21
19
### Scopes
22
20
23
21
r[names.resolution.general.scopes.intro]
24
22
> [!NOTE]
25
-
> This is a placeholder for future expansion about resolution of names through various scopes.
23
+
> This is a placeholder for future expansion about resolution of names within various scopes.
26
24
27
25
r[names.resolution.expansion]
28
26
## Expansion-time name resolution
29
27
30
28
r[names.resolution.expansion.intro]
31
-
Expansion-time name resolution is the stage of name resolution necessary to complete macro expansion and fully generate a crate's AST. This stage requires the resolution of macro invocations and `use` declarations. Resolving `use` declarations is required to resolve [path-based scope] macro invocations. Resolving macro invocations is required in order to expand them.
29
+
Expansion-time name resolution is the stage of name resolution necessary to complete macro expansion and fully generate a crate's [AST]. This stage requires the resolution of macro invocations and `use` declarations. Resolving `use` declarations is required for macro invocations that resolve via [path-based scope]. Resolving macro invocations is required in order to expand them.
After expansion-time name resolution, the AST must not contain any unexpanded macro invocations. Every macro invocation resolves to a valid definition that exists in the final AST or an external crate.
32
+
After expansion-time name resolution, the AST must not contain any unexpanded macro invocations. Every macro invocation resolves to a valid definition that exists in the final AST or in an external crate.
35
33
36
34
```rust,compile_fail
37
-
fn main() {
38
-
foo!(); // ERROR: cannot find macro `foo` in this scope
39
-
}
35
+
m!(); // ERROR: Cannot find macro `m` in this scope.
The resolution of names must be *stable*. After expansion, names in the fully expanded AST must resolve to the same definition, regardless of the order in which macros are expanded.
39
+
The resolution of names must be stable. After expansion, names in the fully expanded AST must resolve to the same definition regardless of the order in which macros are expanded and imports are resolved.
44
40
45
41
r[names.resolution.expansion.speculation]
46
42
All name resolution candidates selected during macro expansion are considered speculative. Once the crate has been fully expanded, all speculative import resolutions are validated to ensure that macro expansion did not introduce any new ambiguities.
47
43
48
44
> [!NOTE]
49
-
>
50
-
> Due to the iterative nature of macro expansion, this causes so called time traveling ambiguities, such as when a macro or glob import introduces an item that is ambiguous with its own base path.
45
+
> Due to the iterative nature of macro expansion, this causes so-called time traveling ambiguities, such as when a macro or glob import introduces an item that is ambiguous with its own base path.
51
46
>
52
47
> ```rust,compile_fail,E0659
53
-
> macro_rules! m {
54
-
> () => { mod bar {} }
48
+
> # fn main() {}
49
+
> macro_rules! f {
50
+
> () => {
51
+
> mod m {
52
+
> pub(crate) use f;
53
+
> }
54
+
> }
55
55
> }
56
+
> f!();
56
57
>
57
-
> mod bar {
58
-
> pub(crate) use m;
59
-
> }
60
-
>
61
-
> fn f() {
62
-
> // * Initially speculatively resolve `bar` to the module in the crate root.
63
-
> // * Expansion of `m` introduces a second bar module inside the body of `f`.
64
-
> // * Expansion-time resolution finalizes resolutions by re-resolving all
65
-
> // imports and macro invocations, sees the introduced ambiguity
66
-
> // and reports it as an error.
67
-
> bar::m!(); // ERROR: `bar` is ambiguous
68
-
> }
58
+
> const _: () = {
59
+
> // Initially, we speculatively resolve `m` to the module in
60
+
> // the crate root.
61
+
> //
62
+
> // Expansion of `f` introduces a second `m` module inside this
63
+
> // body.
64
+
> //
65
+
> // Expansion-time resolution finalizes resolutions by re-
66
+
> // resolving all imports and macro invocations, sees the
67
+
> // introduced ambiguity and reports it as an error.
0 commit comments