Questions: Semantic Analysis Phase

Question 1

A program passes the parser successfully but fails during semantic analysis. Which of the following is the most likely cause?

• A. The program has a syntax error — a missing semicolon or mismatched brace
• B. The program uses a variable that was never declared in the current scope
• C. The program has an infinite loop that the compiler detected
• D. The program uses an unsupported keyword not in the grammar

Answer: (B)

Parsing only checks structural correctness — whether the program follows the grammar rules. An undeclared variable is syntactically valid (the grammar allows any identifier in an expression position) but semantically invalid (the symbol table lookup fails). Option A describes a syntax error, which the *parser* would catch — it never reaches semantic analysis. Option C (infinite loop detection) is the halting problem, which compilers generally cannot solve. Option D (unsupported keyword) would fail at lexing or parsing, not semantic analysis.

Question 2

During semantic analysis, type checking proceeds bottom-up through the AST. Which of the following best explains why this direction is correct?

• A. Bottom-up processing is faster than top-down, which is why compilers prefer it
• B. Types of composite expressions depend on the types of their subexpressions — you must know the parts before you can determine the whole
• C. The symbol table is built top-down, so type checking must go in the opposite direction to avoid conflicts
• D. Top-down type checking would require the compiler to know the expected type before reading the expression, which is only needed for type inference

Answer: (B)

Type checking is bottom-up because an expression's type is computed from its children. The type of `a + b` cannot be determined until the types of `a` and `b` are known. Literals have base types (e.g., `3` is int); variables get their types from symbol table lookups; operators combine the types of their operands according to typing rules. This is a natural post-order traversal of the AST: process children, then combine their results at the parent. Option D has a grain of truth about type inference but does not explain why basic type checking is bottom-up.

Question 3

Semantic analysis can catch most runtime errors, so a program that passes semantic analysis will execute without errors.

• T. True
• F. False

Answer: False

Semantic analysis catches a specific class of errors detectable at compile time from the program's static structure: undeclared variables, type mismatches, arity errors, contextual constraint violations. It cannot catch dynamic errors that depend on runtime values — array index out of bounds, null pointer dereferences, division by zero (when the divisor is a variable), or any error whose occurrence depends on input data. Static analysis is inherently incomplete for this reason: the set of runtime behaviors is undecidable in general. Semantic analysis is the last line of defense the compiler can offer, not a guarantee of correct execution.

Question 4

The output of semantic analysis is the same AST produced by the parser, since semantic analysis mainly checks for errors without modifying the tree.

• T. True
• F. False

Answer: False

Semantic analysis produces a *decorated* (or annotated) AST — the original tree augmented with type information at each node. This decoration is not optional; it is essential for the next compiler phase. Code generation must know the type of every expression to emit correct machine code (e.g., whether `+` should compile to an integer add instruction, a floating-point add, or a string concatenation). Without type annotations on the AST, the code generator would need to re-derive types, duplicating work. The decorated AST is the primary output that later phases consume.

Question 5

What is the role of the symbol table during semantic analysis, and what two types of errors does it enable the compiler to detect?

Model answer: The symbol table records all declared identifiers — their names, types, scopes, and attributes (e.g., whether a variable is a const, a function's parameter list). During semantic analysis, the AST walk consults the symbol table on every identifier use. This enables detection of two major error classes: (1) *use-before-declaration errors* — an identifier is used but has no entry in the current scope chain (undeclared variable or function); (2) *type mismatch errors* — the declared type of an identifier conflicts with how it is being used (e.g., calling an integer as a function, assigning a string to an int variable, passing the wrong number of arguments). The symbol table is what connects the declaration site of every name to all its use sites.

The scope structure of the symbol table (nested scopes, block scoping) is critical for getting name resolution right in languages with shadowing or block scoping. Semantic analysis must enter and exit scopes in sync with the AST traversal so that the correct declarations are visible at each use site — the same way the runtime would resolve names during execution. Getting this right is why semantic analysis is a non-trivial phase despite not generating any code.