Semantic Analysis and Type Checking
The final phase of the frontend compiler pipeline. Learn how the compiler ensures type safety and semantic correctness before generating intermediate code.
Learning Goals
- Explain the role of semantic analysis as the phase that checks meaning beyond syntax.
- Describe how the compiler cross-references attributes stored in the symbol table to ensure variables and functions are used correctly.
- Trace type checking step-by-step on an expression involving mixed types and coercion.
- Differentiate between type coercion (implicit) and type casting (explicit).
- Explain scope rules and how the semantic analyzer enforces declaration-before-use.
- Compare static scope (lexical) vs dynamic scope with code examples.
- Differentiate between static and dynamic type checking.
- Distinguish strong vs weak typing and name vs structural type equivalence.
- Identify common semantic errors and understand why static type checking is preferred in compiled languages.
The Role of Semantic Analysis
Semantic analysis is the compiler phase that checks the meaning of a program beyond its grammatical structure. While syntax analysis verifies that tokens follow the grammar rules (e.g., an assignment has the form identifier = expression), semantic analysis verifies that the assignment is semantically valid — the identifier has been declared, the expression's type is compatible with the identifier's type, and no rules are violated.
Key responsibilities of the semantic analyzer:
| Responsibility | Description |
|---|---|
| Type Checking | Verifies that operands of each operator are type-compatible. |
| Scope Resolution | Determines which declaration a variable reference refers to. |
| Declaration Before Use | Ensures every identifier is declared before it is referenced. |
| Function Matching | Checks that function calls match declared parameter types and count. |
| Coercion Insertion | Adds implicit type conversion nodes where widening is needed. |
Type Checking & Symbol Table Integration
Type checking is entirely dependent on the Symbol Table. The compiler cannot check types just by looking at the syntax tree; it must cross-reference historical data stored during earlier declarations.
When the parser produces a parse tree, the semantic analyzer walks it and annotates each node with type information drawn from the symbol table. The result is an annotated AST — a tree where every expression node carries its computed type and every coercion is explicitly marked.
Trace: Type Checking on `a = b + c`
- 1Step 1
The analyzer retrieves types for
a,b, andc. Current state:a: floatb: intc: float
- 2Step 2
For
b + c, the analyzer seesint + float. Sinceintcan be widened tofloatsafely, it decides to perform implicit coercion. - 3Step 3
The analyzer inserts a node:
int_to_float(b). The expression becomesint_to_float(b) + c. The result type of this addition is nowfloat. - 4Step 4
The final assignment
a = float_resultis checked. Sinceais afloat, the operation is semantically valid.
Annotated AST Visualization
The tree below illustrates how the semantic analyzer transforms a raw parse tree by inserting explicit coercion nodes:
Coercion vs. Casting
Coercion is implicit and automatic (e.g., int → float). It is safe widening.
Casting is explicit and programmer-driven (e.g., (int)3.9). It can be narrowing and may result in data loss.
Scope Rules and Declaration Checking
Scope is the region of program text where a particular declaration is visible. The semantic analyzer enforces two critical rules:
- Declaration before use: Every identifier must be declared before it is referenced.
- Uniqueness: No duplicate declarations of the same name are allowed within the same scope level.
Also called Lexical Scope. Scope is determined by the source code structure. A reference resolves to the declaration in the closest enclosing block in the text.
Used by: C, Java, Python, Rust.
Frequently Asked Questions
Knowledge Check
If a compiler implicitly converts an int to a float during type checking, this is known as: