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: Sources/SwiftLexicalLookup/SwiftLexicalLookup.docc/LookupRules.md
+10-8Lines changed: 10 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
# Unqualified Lookup Rules
2
2
3
3
## Overview
4
-
Unqualified lookup can be initiated from any source position, optionally targeting a specific identifier for name comparison. Unqualified lookup traverses the syntax tree from bottom-up, collecting names that match the lookup criteria. A name matches the lookup if the specified identifier (if present) refers to the introduced name and the position from which the unqualified lookup was triggered is preceded by the position where the name was introduced (if specified).
4
+
Unqualified lookup can be initiated from any source position, optionally targeting a specific identifier for name comparison. Unqualified lookup traverses the syntax tree from bottom-up, collecting names that match the lookup criteria. A name matches the lookup if the specified identifier (if present) refers to the introduced name and the position from which the unqualified lookup was triggered is preceded by the position where the name was introduced, provided the name enforces position based availability by itself (such exceptions are for example type declarations).
5
5
6
6
## Default Scope Behavior
7
7
Names are introduced and their availabilities are set by special syntax nodes referred to as syntax scopes or simply scopes. By default, each scope for lookup produces a result object that associates the scope of origin with the matched names. Lookup is then invoked on the parent scope, i.e., the closest syntax scope ancestor of the original scope in the syntax tree.
@@ -15,10 +15,11 @@ There are three distinct kinds of names identified by unqualified lookup:
15
15
## Specialized Scopes
16
16
Some scopes share common behavior and can be further generalized as follows:
17
17
-**Type Scope** (`TypeScopeSyntax`): Implicitly introduces `self` and `Self` names.
18
-
-**Sequential Scope** (`SequentialScopeSyntax`): Interleaves its own results with results produced by introducing to sequential parent scopes when encountered during name extraction. Results are ordered from closest to furthest from the unqualified lookup position.
18
+
-**Sequential Scope** (`SequentialScopeSyntax`): Interleaves its own results with results produced by *Introducing to Sequential Parent Scopes* when encountered during name extraction. Results are ordered from closest to furthest from the unqualified lookup position.
19
19
-**Introducing to Sequential Parent Scope** (`IntroducingToSequentialParentScopeSyntax`): Produces a result that is later interleaved with the results produced by its sequential parent.
20
20
21
-
> Example of Sequential Scope behavior (code block):
21
+
> Example:
22
+
> Sequential Scope behavior (code block):
22
23
> ```swift
23
24
>funcfoo(x: Int?) {
24
25
>// Guard scope
@@ -38,20 +39,21 @@ Some scopes share common behavior and can be further generalized as follows:
38
39
> }
39
40
> ```
40
41
> When looking up the reference `a`, we get4 results in total, going from the bottom to the top of the source code: the `a` declaration associated with the function's code block body scope, the `a` variable associated with the bottom-most `guard`, another `a` declaration associated with the code block, and finally the `a` introduced in the top-most `guard`.
41
-
> When looking up `b`, on the other hand, we get just one result — the `b` declaration inside the bottom-most `guard`.
42
+
> When looking up `b`, on the other hand, we get just one result: the `b` declaration inside the bottom-most `guard`.
42
43
43
-
-**With Generic Parameters Scope** (`WithGenericParametersScopeSyntax`): Instead of invoking lookup on its parent scope, it first tries to pass it to the generic parameter scopeif available.
44
-
-**Generic Parameter Scope** (`GenericParameterScopeSyntax`): Instead of invoking lookup on its parent scope, it first tries to invoke it on the with-generic-parameters scope's parent.
44
+
-**With Generic Parameters Scope** (`WithGenericParametersScopeSyntax`): Instead of invoking lookup on its parent scope, it first tries to pass it to the *Generic Parameter Scope*if available.
45
+
-**Generic Parameter Scope** (`GenericParameterScopeSyntax`): Instead of invoking lookup on its parent scope, it first tries to invoke it on the *With Generic Parameters Scope's* parent.
45
46
46
-
> Example of Generic Parameter Scope Behavior:
47
+
> Example:
48
+
> Generic Parameter Scope Behavior:
47
49
> ```swift
48
50
>class Foo<A, B: A> { // <-- lookup here
49
51
>funcbar<A, C>() {
50
52
> X // <-- lookup here
51
53
> }
52
54
> }
53
55
> ```
54
-
> When starting the lookup from the location marked `X` without name matching, we get two results. The first is associated with the generic parameter scope of the `bar` function, containing the names `A` and `C` in that exact order. The second is associated with the class`Foo`, containing the names `A` and `B` in that exact order.
56
+
> When starting the lookup from the location marked `X` without identifier matching, we get two results. The first is associated with the generic parameter scope of the `bar` function, containing the names `A` and `C` in that exact order. The second is associated with the class`Foo`, containing the names `A` and `B` in that exact order.
55
57
> When performing lookup at the `A` reference in the `Foo` class generic parameter clause, the generic parameter `A` introduced inside the clause is returned as in the result.
0 commit comments