|
207
|
1 <!--===- docs/Semantics.md
|
|
|
2
|
|
|
3 Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
4 See https://llvm.org/LICENSE.txt for license information.
|
|
|
5 SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
6
|
|
|
7 -->
|
|
|
8
|
|
|
9 # Semantic Analysis
|
|
|
10
|
|
|
11 ```eval_rst
|
|
|
12 .. contents::
|
|
|
13 :local:
|
|
|
14 ```
|
|
|
15
|
|
|
16 The semantic analysis pass determines if a syntactically correct Fortran
|
|
|
17 program is is legal by enforcing the constraints of the language.
|
|
|
18
|
|
|
19 The input is a parse tree with a `Program` node at the root;
|
|
|
20 and a "cooked" character stream, a contiguous stream of characters
|
|
|
21 containing a normalized form of the Fortran source.
|
|
|
22
|
|
|
23 The semantic analysis pass takes a parse tree for a syntactically
|
|
|
24 correct Fortran program and determines whether it is legal by enforcing
|
|
|
25 the constraints of the language.
|
|
|
26
|
|
|
27 If the program is not legal, the results of the semantic pass will be a list of
|
|
|
28 errors associated with the program.
|
|
|
29
|
|
|
30 If the program is legal, the semantic pass will produce a (possibly modified)
|
|
|
31 parse tree for the semantically correct program with each name mapped to a symbol
|
|
|
32 and each expression fully analyzed.
|
|
|
33
|
|
|
34 All user errors are detected either prior to or during semantic analysis.
|
|
|
35 After it completes successfully the program should compile with no error messages.
|
|
|
36 There may still be warnings or informational messages.
|
|
|
37
|
|
|
38 ## Phases of Semantic Analysis
|
|
|
39
|
|
|
40 1. [Validate labels](#validate-labels) -
|
|
|
41 Check all constraints on labels and branches
|
|
|
42 2. [Rewrite DO loops](#rewrite-do-loops) -
|
|
|
43 Convert all occurrences of `LabelDoStmt` to `DoConstruct`.
|
|
|
44 3. [Name resolution](#name-resolution) -
|
|
|
45 Analyze names and declarations, build a tree of Scopes containing Symbols,
|
|
|
46 and fill in the `Name::symbol` data member in the parse tree
|
|
|
47 4. [Rewrite parse tree](#rewrite-parse-tree) -
|
|
|
48 Fix incorrect parses based on symbol information
|
|
|
49 5. [Expression analysis](#expression-analysis) -
|
|
|
50 Analyze all expressions in the parse tree and fill in `Expr::typedExpr` and
|
|
|
51 `Variable::typedExpr` with analyzed expressions; fix incorrect parses
|
|
|
52 based on the result of this analysis
|
|
|
53 6. [Statement semantics](#statement-semantics) -
|
|
|
54 Perform remaining semantic checks on the execution parts of subprograms
|
|
|
55 7. [Write module files](#write-module-files) -
|
|
|
56 If no errors have occurred, write out `.mod` files for modules and submodules
|
|
|
57
|
|
|
58 If phase 1 or phase 2 encounter an error on any of the program units,
|
|
|
59 compilation terminates. Otherwise, phases 3-6 are all performed even if
|
|
|
60 errors occur.
|
|
|
61 Module files are written (phase 7) only if there are no errors.
|
|
|
62
|
|
|
63 ### Validate labels
|
|
|
64
|
|
|
65 Perform semantic checks related to labels and branches:
|
|
|
66 - check that any labels that are referenced are defined and in scope
|
|
|
67 - check branches into loop bodies
|
|
|
68 - check that labeled `DO` loops are properly nested
|
|
|
69 - check labels in data transfer statements
|
|
|
70
|
|
|
71 ### Rewrite DO loops
|
|
|
72
|
|
|
73 This phase normalizes the parse tree by removing all unstructured `DO` loops
|
|
|
74 and replacing them with `DO` constructs.
|
|
|
75
|
|
|
76 ### Name resolution
|
|
|
77
|
|
|
78 The name resolution phase walks the parse tree and constructs the symbol table.
|
|
|
79
|
|
|
80 The symbol table consists of a tree of `Scope` objects rooted at the global scope.
|
|
|
81 The global scope is owned by the `SemanticsContext` object.
|
|
|
82 It contains a `Scope` for each program unit in the compilation.
|
|
|
83
|
|
|
84 Each `Scope` in the scope tree contains child scopes representing other scopes
|
|
|
85 lexically nested in it.
|
|
|
86 Each `Scope` also contains a map of `CharBlock` to `Symbol` representing names
|
|
|
87 declared in that scope. (All names in the symbol table are represented as
|
|
|
88 `CharBlock` objects, i.e. as substrings of the cooked character stream.)
|
|
|
89
|
|
|
90 All `Symbol` objects are owned by the symbol table data structures.
|
|
|
91 They should be accessed as `Symbol *` or `Symbol &` outside of the symbol
|
|
|
92 table classes as they can't be created, copied, or moved.
|
|
|
93 The `Symbol` class has functions and data common across all symbols, and a
|
|
|
94 `details` field that contains more information specific to that type of symbol.
|
|
|
95 Many symbols also have types, represented by `DeclTypeSpec`.
|
|
|
96 Types are also owned by scopes.
|
|
|
97
|
|
|
98 Name resolution happens on the parse tree in this order:
|
|
|
99 1. Process the specification of a program unit:
|
|
|
100 1. Create a new scope for the unit
|
|
|
101 2. Create a symbol for each contained subprogram containing just the name
|
|
|
102 3. Process the opening statement of the unit (`ModuleStmt`, `FunctionStmt`, etc.)
|
|
|
103 4. Process the specification part of the unit
|
|
|
104 2. Apply the same process recursively to nested subprograms
|
|
|
105 3. Process the execution part of the program unit
|
|
|
106 4. Process the execution parts of nested subprograms recursively
|
|
|
107
|
|
|
108 After the completion of this phase, every `Name` corresponds to a `Symbol`
|
|
|
109 unless an error occurred.
|
|
|
110
|
|
|
111 ### Rewrite parse tree
|
|
|
112
|
|
|
113 The parser cannot build a completely correct parse tree without symbol information.
|
|
|
114 This phase corrects mis-parses based on symbols:
|
|
|
115 - Array element assignments may be parsed as statement functions: `a(i) = ...`
|
|
|
116 - Namelist group names without `NML=` may be parsed as format expressions
|
|
|
117 - A file unit number expression may be parsed as a character variable
|
|
|
118
|
|
|
119 This phase also produces an internal error if it finds a `Name` that does not
|
|
|
120 have its `symbol` data member filled in. This error is suppressed if other
|
|
|
121 errors have occurred because in that case a `Name` corresponding to an erroneous
|
|
|
122 symbol may not be resolved.
|
|
|
123
|
|
|
124 ### Expression analysis
|
|
|
125
|
|
|
126 Expressions that occur in the specification part are analyzed during name
|
|
|
127 resolution, for example, initial values, array bounds, type parameters.
|
|
|
128 Any remaining expressions are analyzed in this phase.
|
|
|
129
|
|
|
130 For each `Variable` and top-level `Expr` (i.e. one that is not nested below
|
|
|
131 another `Expr` in the parse tree) the analyzed form of the expression is saved
|
|
|
132 in the `typedExpr` data member. After this phase has completed, the analyzed
|
|
|
133 expression can be accessed using `semantics::GetExpr()`.
|
|
|
134
|
|
|
135 This phase also corrects mis-parses based on the result of expression analysis:
|
|
|
136 - An expression like `a(b)` is parsed as a function reference but may need
|
|
|
137 to be rewritten to an array element reference (if `a` is an object entity)
|
|
|
138 or to a structure constructor (if `a` is a derive type)
|
|
|
139 - An expression like `a(b:c)` is parsed as an array section but may need to be
|
|
|
140 rewritten as a substring if `a` is an object with type CHARACTER
|
|
|
141
|
|
|
142 ### Statement semantics
|
|
|
143
|
|
|
144 Multiple independent checkers driven by the `SemanticsVisitor` framework
|
|
|
145 perform the remaining semantic checks.
|
|
|
146 By this phase, all names and expressions that can be successfully resolved
|
|
|
147 have been. But there may be names without symbols or expressions without
|
|
|
148 analyzed form if errors occurred earlier.
|
|
|
149
|
|
|
150 ### Initialization processing
|
|
|
151
|
|
|
152 Fortran supports many means of specifying static initializers for variables,
|
|
|
153 object pointers, and procedure pointers, as well as default initializers for
|
|
|
154 derived type object components, pointers, and type parameters.
|
|
|
155
|
|
|
156 Non-pointer static initializers of variables and named constants are
|
|
|
157 scanned, analyzed, folded, scalar-expanded, and validated as they are
|
|
|
158 traversed during declaration processing in name resolution.
|
|
|
159 So are the default initializers of non-pointer object components in
|
|
|
160 non-parameterized derived types.
|
|
|
161 Name constant arrays with implied shapes take their actual shape from
|
|
|
162 the initialization expression.
|
|
|
163
|
|
|
164 Default initializers of non-pointer components and type parameters
|
|
|
165 in distinct parameterized
|
|
|
166 derived type instantiations are similarly processed as those instances
|
|
|
167 are created, as their expressions may depend on the values of type
|
|
|
168 parameters.
|
|
|
169 Error messages produced during parameterized derived type instantiation
|
|
|
170 are decorated with contextual attachments that point to the declarations
|
|
|
171 or other type specifications that caused the instantiation.
|
|
|
172
|
|
|
173 Static initializations in `DATA` statements are collected, validated,
|
|
|
174 and converted into static initialization in the symbol table, as if
|
|
|
175 the initialized objects had used the newer style of static initialization
|
|
|
176 in their entity declarations.
|
|
|
177
|
|
|
178 All statically initialized pointers, and default component initializers for
|
|
|
179 pointers, are processed late in name resolution after all specification parts
|
|
|
180 have been traversed.
|
|
|
181 This allows for forward references even in the presence of `IMPLICIT NONE`.
|
|
|
182 Object pointer initializers in parameterized derived type instantiations are
|
|
|
183 also cloned and folded at this late stage.
|
|
|
184 Validation of pointer initializers takes place later in declaration
|
|
|
185 checking (below).
|
|
|
186
|
|
|
187 ### Declaration checking
|
|
|
188
|
|
|
189 Whenever possible, the enforcement of constraints and "shalls" pertaining to
|
|
|
190 properties of symbols is deferred to a single read-only pass over the symbol table
|
|
|
191 that takes place after all name resolution and typing is complete.
|
|
|
192
|
|
|
193 ### Write module files
|
|
|
194
|
|
|
195 Separate compilation information is written out on successful compilation
|
|
|
196 of modules and submodules. These are used as input to name resolution
|
|
|
197 in program units that `USE` the modules.
|
|
|
198
|
|
|
199 Module files are stripped down Fortran source for the module.
|
|
|
200 Parts that aren't needed to compile dependent program units (e.g. action statements)
|
|
|
201 are omitted.
|
|
|
202
|
|
|
203 The module file for module `m` is named `m.mod` and the module file for
|
|
|
204 submodule `s` of module `m` is named `m-s.mod`.
|
