authorgravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2018-07-06 18:24:09-04:00
committergravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2018-07-06 18:24:09-04:00
loge19f0b5d9c26f4d309df9cfc84b7e5dc04b10ed5
tree998094f5926498029a9d2b42668f83bafd0d1ca5
parent4ad4cd26541258a84faf97e9fe07a69fadc57c66

remove outdated semantic analysis documentation

1 files changed, 0 insertions(+), 74 deletions(-)

doc/semantic_analysis.md deleted-74
...@@ -1,74 +0,0 @@
1# How Semantic Analysis Works
2
3We start with a set of files. Typically the user only has one entry point file,
4which imports the other files they want to use. However, the compiler may
5choose to add more files to the compilation, for example bootstrap.zig which
6contains the code that calls main.
7
8Our goal now is to treat everything that is marked with the `export` keyword
9as a root node, and then parse and semantically analyze as little as possible
10in order to fulfill these exports.
11
12So, some parts of the code very well may have uncaught semantic errors, but as
13long as the code is not referenced in any way, the compiler will not complain
14because the code may as well not exist. This is similar to the fact that code
15excluded from compilation with an `#ifdef` in C is not analyzed. Avoiding
16analyzing unused code will save compilation time - one of Zig's goals.
17
18So, for each file, we iterate over the top level declarations. The set of top
19level declarations are:
20
21 * Function Definition
22 * Global Variable Declaration
23 * Container Declaration (struct or enum)
24 * Error Value Declaration
25 * Use Declaration
26
27Each of these can have `export` attached to them except for error value
28declarations and use declarations.
29
30When we see a top level declaration during this iteration, we determine its
31unique name identifier within the file. For example, for a function definition,
32the unique name identifier is simply its name. Using this name we add the top
33level declaration to a map.
34
35If the top level declaration is exported, we add it to a set of exported top
36level identifiers.
37
38If the top level declaration is a use declaration, we add it to a set of use
39declarations.
40
41If the top level declaration is an error value declaration, we assign it a value
42and increment the count of error values.
43
44After this preliminary iteration over the top level declarations, we iterate
45over the use declarations and resolve them. To resolve a use declaration, we
46analyze the associated expression, verify that its type is the namespace type,
47and then add all the items from the namespace into the top level declaration
48map for the current file.
49
50To analyze an expression, we recurse the abstract syntax tree of the
51expression. Whenever we must look up a symbol, if the symbol exists already,
52we can use it. Otherwise, we look it up in the top level declaration map.
53If it exists, we can use it. Otherwise, we interrupt resolving this use
54declaration to resolve the next one. If a dependency loop is detected, emit
55an error. If all use declarations are resolved yet the symbol we need still
56does not exist, emit an error.
57
58To analyze an `@import` expression, find the referenced file, parse it, and
59add it to the set of files to perform semantic analysis on.
60
61Proceed through the rest of the use declarations the same way.
62
63If we make it through the use declarations without an error, then we have a
64complete map of all globals that exist in the current file.
65
66Next we iterate over the set of exported top level declarations.
67
68If it's a function definition, add it to the set of exported function
69definitions and resolve the function prototype only. Otherwise, resolve the
70top level declaration completely. This may involve recursively resolving other
71top level declarations that expressions depend on.
72
73Finally, iterate over the set of exported function definitions and analyze the
74bodies.