简介这份资源是编译原理课程中语义分析实验的完整工程包面向正在学习编译器设计、需要完成类似Java语义分析实验的高校学生或自学者。内容围绕编译原理的语义分析阶段展开涵盖词法分析、语法分析后的类型检查、作用域解析、常量折叠等核心处理逻辑工程文件以35个Java源码为主配合14个XML工程配置与相关class文件便于直接导入IDE进行阅读、调试和二次修改。压缩包内共101个文件整体大小仅88KB结构紧凑适合快速理解一个简易编译器在语义分析环节的代码组织方式与实现思路。目前已有1781人学习下载适合作为实验参考或期末设计底稿使用。通过分析该工程读者可以直观看到Java实现语义分析时常见的符号表管理与类型校验写法也能借助其中少量txt说明与工程状态文件了解项目构建过程对巩固编译原理理论、提升工程阅读能力有一定帮助。1. 编译原理实验三的语义分析语法检查过了不代表程序是对的很多人在编译原理实验课走到第三周时会发现一个奇怪现象词法分析写得很顺语法分析勉强能跑但到了语义分析这一步整个程序像突然变成一个黑匣子——同样的输入别人报 3 个错误你报 30 个别人能指出“第 12 行类型不匹配”你只能停在“第 5 行无法继续分析”。这是因为语义分析不再关心“句子结构合不合文法”而是关心“这段程序到底有没有意义”。实验三的 sectionnef 语义分析任务本质上不是让你再写一个解析器而是让你在解析过程中回答四类问题这个名字在哪声明过、它的类型对不对、作用域有没有串层、函数调用合不合法。适合对词法语法已经上手、想把这门课真正吃透的本科生也适合想快速补上符号表、类型检查这块空白的从业者。这篇笔记把 sectionnef 拆成可实现的步骤从符号表设计到类型检查每一步都给你能直接落地的代码和参数。2. 先从 sectionnef 里拆出语义分析要管的四件事类型、作用域、声明与检查时机2.1 语法分析管“结构”语义分析管“约束”很多同学的误区是把语法分析做得过重。语法分析的任务是判断int a b c;是否符合文法它看到的是 Token 序列只看形状语义分析才开始关心b是否被声明过、c是不是能参与加法运算。举个例子x y 1;在语法上完全合法但如果x和y都没声明语义分析就必须报错。换句话说语法分析告诉你“这句话能不能说”语义分析告诉你“这句话说了算不算”。对 sectionnef 这个实验我一般建议先把它当作一个固定测试集来做而不是一上来就写通用编译器。你先把实验给定的 sectionnef 输入跑一遍数一数预期要报多少个错误、分布在哪些行再决定符号表和类型检查的深度。常见做法是把语义分析拆成以下四件事对应绝大多数课程实验的评分点检查项典型错误在 sectionnef 里的落点声明检查未声明标识符、重复声明变量和函数的名字是否出现在符号表中作用域管理变量遮蔽、作用域泄漏嵌套块、函数体与全局作用域的进出时机类型检查赋值不匹配、运算数类型不兼容int、float、以及函数返回值类型调用约束参数个数不对、参数类型不对函数调用的实参类型与形参声明一致性这四件事不是平行的它们共用同一张符号表。先有符号表才能谈类型检查先有作用域栈才能保证符号表在退出块之后不会残留脏数据。我见过不少翻车现场是因为把四件事拆成四个独立模块结果每个模块各维护一张表最后查错误时发现同一个变量在两个模块里类型不同。请从一开始就定死一张表。2.2 语法制导翻译语义动作应该在什么时候执行语义分析和语法分析的黏合方式是语法制导翻译Syntax-Directed Translation。简单说就是在语法分析过程中每识别出一个产生式就执行一段附属的语义动作。这里要区分两个概念综合属性Synthesized Attribute和继承属性Inherited Attribute。综合属性由子节点向上传递典型例子是表达式类型a b的类型由a和b的类型经过运算符规则计算得出最后回传给父节点。继承属性由父节点向下传递典型例子是语句的期望类型int x expr;要求expr的类型能赋值给int这个“期望类型”是声明语句传给表达式节点的。在递归下降分析器里这两类属性分别对应两种编码方式。继承属性就是方法参数综合属性就是方法返回值。别小看这个结论——很多人上课听属性文法听得云里雾里实际写代码时只要记住一句话需要从外部传入的信息写成参数需要往上汇报的信息写成返回值。sectionnef 这种规模的教学语言完全不需要引入 Yacc/Bison 之类的生成器手写递归下降就能把语义动作缝进每个 parse 方法里。2.3 设计一张贯穿全程的符号表接口符号表是语义分析的心脏。我建议先用一个最小的接口把数据结构定下来后面无论写类型检查还是函数调用检查都只依赖这张表。接口层设计成支持作用域嵌套每个作用域是一张表表与表之间通过 parent 指针串成链。查询名字时先查当前层查不到就顺着 parent 往上找直到全局层。这个结构既能处理嵌套块也能处理函数体内部局部变量访问全局变量的情况。public class SymbolTable { private final SymbolTable parent; private final MapString, Symbol symbols new HashMap(); public SymbolTable(SymbolTable parent) { this.parent parent; } public void define(Symbol sym) { symbols.put(sym.name, sym); } public Symbol lookupLocal(String name) { return symbols.get(name); } public Symbol lookup(String name) { Symbol s symbols.get(name); if (s ! null) { return s; } return parent ! null ? parent.lookup(name) : null; } }这里两个方法要区分清楚lookupLocal只查当前层用于重复声明检测lookup会沿作用域链向上查找用于普通的名字解析。参数parent是构造作用域链的关键进入一个新块时把当前表传进去建新表退出时丢弃新表即可。很多同学漏掉的是重复声明检查必须用lookupLocal而不是lookup。否则在内层声明一个和外层同名的变量时会把它误判成重复声明。这个细节我后面还会再讲。3. 用 Java 手写符号表与类型检查器能跑通 sectionnef 的最小实现3.1 符号节点变量和函数要放进同一个结构符号表里存的不只是“名字 → 类型”的映射还需要存行号因为实验判题通常要求报错信息带位置。我常用的 Symbol 类长这样public enum Type { INT, FLOAT, BOOL, VOID, ERROR } public class Symbol { public final String name; public final Type type; public final int line; public final ListType paramTypes; public Symbol(String name, Type type, int line, ListType paramTypes) { this.name name; this.type type; this.line line; this.paramTypes paramTypes; } }变量和函数共用这一个类变量声明时paramTypes传null或空表函数声明时把形参类型依次填进去。line字段有两个用途一是报错时告诉用户“这个标识符第一次声明在哪”二是做重复声明检查时把旧位置和新位置一起打出来。Type.ERROR是一个很实用的设置——表达式的类型检查一旦遇到错误就返回这种特殊类型后面做级联错误抑制时全靠它我写第三节和第四节都会用到。3.2 错误收集器不要一报错就 System.exit课程实验里最常见的翻车方式是在语义错误时直接抛异常或System.exit结果一个错误就让整个分析中断。判题程序希望你一次运行报出所有错误而不是只报第一个。我一般会把错误诊断统一收集到一个列表里最后按行号排序输出。这样做还有一个好处可以区分 Error 和 Warning很多 assignment 对“警告”不计分但对“错误”严格计分。public class Diagnostic { public final String severity; public final int line; public final int col; public final String message; public Diagnostic(String severity, int line, int col, String message) { this.severity severity; this.line line; this.col col; this.message message; } } public class ErrorReporter { private final ListDiagnostic diagnostics new ArrayList(); public void error(int line, int col, String msg) { diagnostics.add(new Diagnostic(error, line, col, msg)); } public void warn(int line, int col, String msg) { diagnostics.add(new Diagnostic(warning, line, col, msg)); } public boolean hasErrors() { return diagnostics.stream() .anyMatch(d - d.severity.equals(error)); } public void flush(PrintStream out) { diagnostics.stream() .sorted(Comparator.comparingInt((Diagnostic d) - d.line) .thenComparingInt(d - d.col)) .forEach(d - out.printf(%d:%d: %s: %s%n, d.line, d.col, d.severity, d.message)); } }注意flush里的排序逻辑按line排行号相同再按col排。判题系统经常把标准输出逐行比对你把诊断顺序固定下来能少踩很多测试比对不一致的坑。这段代码里的PrintStream参数建议传入System.out但测试时你完全可以用一个ByteArrayOutputStream把输出接走方便做自动化断言。3.3 类型检查的最小规则把隐式转换表做成可配置类型检查器本质是一张二维决策表左边是期望类型上边是实际类型交叉点写“允许”或“不允许”。sectionnef 这类教学语言通常只有 int 和 float比较常见的规定是int 可以隐式转成 floatfloat 不能隐式转成 intbool 只能参与条件判断。我把这个规则写成一个小方法public static boolean canAssign(Type target, Type actual) { if (target actual) { return true; } if (target Type.FLOAT actual Type.INT) { return true; } return false; }canAssign这个语义动作在变量声明和赋值语句里都会被调用。举一个实际检查代码的例子假设语法分析器正在处理一条变量声明语句它已经拿到了声明的类型declaredType、变量名 Tokenname和初始化表达式的类型initTypeprivate void checkVarDecl(Token name, Type declaredType, Type initType) { if (!canAssign(declaredType, initType)) { reporter.error(name.line, name.col, 变量的初始值类型不匹配期望 declaredType 实际得到 initType); } Symbol prev currentScope.lookupLocal(name.lexeme); if (prev ! null) { reporter.error(name.line, name.col, 重复声明 name.lexeme 第一次声明在第 prev.line 行); } currentScope.define(new Symbol(name.lexeme, declaredType, name.line, null)); }这里的检查顺序是有讲究的先做类型检查再做重复声明检查最后才把符号定义进当前作用域。如果顺序反过来一旦重复声明新符号会覆盖旧符号的记录报错信息里就丢失了“第一次声明在第几行”这个关键数据。这份代码里的参数declaredType是继承属性由调用它的声明解析方法传入而initType是综合属性来自表达式解析方法的返回值。4. 按 sectionnef 的规则做语法制导翻译把语义动作缝进递归下降分析器4.1 表达式解析让每个 parse 方法返回类型手工递归下降解析表达式的最大优势是解析的栈本身就是语法树你不用显式构造 AST只要把每个子表达式的类型作为返回值向上抛即可。以最简单的 primary 表达式为例private Type parsePrimary() { if (match(TokenType.INT_LITERAL)) { return Type.INT; } if (match(TokenType.FLOAT_LITERAL)) { return Type.FLOAT; } if (match(TokenType.TRUE, TokenType.FALSE)) { return Type.BOOL; } if (match(TokenType.IDENTIFIER)) { Token ident previous(); Symbol sym currentScope.lookup(ident.lexeme); if (sym null) { reporter.error(ident.line, ident.col, 未声明标识符 ident.lexeme); return Type.ERROR; } return sym.type; } // 其他情形: 括号表达式、一元运算等 return Type.ERROR; }这里有两个关键点。第一currentScope必须是最外层作用域变量每次进入代码块时被替换成新表。第二查不到符号时返回Type.ERROR这样解析仍然能继续往上走父节点拿到ERROR类型后不会继续报一堆没有意义的级联错误。这个参数叫“错误类型的传播抑制”它是语义分析器不崩盘的核心。4.2 二元运算检查运算符决定期望类型二元运算的类型检查要分两个层面运算数的类型本身是否合法以及运算结果的类型是什么。比如 sectionnef 里可能规定加法运算符接受两个数值类型int 或 float取其中较大者作为结果类型比较运算符则要求两个运算数同类型结果为 bool。我一般这样写private Type parseBinaryExpr() { Type left parseUnaryExpr(); while (match(TokenType.PLUS, TokenType.MINUS, TokenType.ASTERISK, TokenType.SLASH, TokenType.EQ_EQ, TokenType.LT, TokenType.GT)) { Token op previous(); Type right parseUnaryExpr(); if (left Type.ERROR || right Type.ERROR) { continue; // 子表达式已经报过错不再重复报 } if (isArithmetic(op)) { if (!isNumeric(left) || !isNumeric(right)) { reporter.error(op.line, op.col, 算术运算符要求数值类型但实际是 left 和 right); left Type.ERROR; } else { left (left Type.FLOAT || right Type.FLOAT) ? Type.FLOAT : Type.INT; } } else { // 比较运算符: 两边类型必须一致, 结果为 BOOL if (left ! right) { reporter.error(op.line, op.col, 比较运算符两侧类型不一致: left vs right); left Type.ERROR; } else { left Type.BOOL; } } } return left; }注意这个循环里的left变量它既是当前解析到的综合属性又作为下一次循环的左操作数类型继续参与计算。这就是语法制导翻译里最朴素的“属性流”——沿着 while 循环一层层往上汇总。如果某个操作数已经是ERROR就用continue跳过本轮的运算符检查避免一行语句报三四个重叠错误。4.3 语句块与作用域进入块时压栈离开块时弹栈递归下降里的语句块是作用域链的开关。处理带花括号的复合语句时千万不要在 parse 方法返回后再恢复旧作用域而要用 try-finally 保证任何提前返回的路径都不会把作用域链弄乱private void parseBlock() { SymbolTable savedScope currentScope; currentScope new SymbolTable(savedScope); try { consume(TokenType.LEFT_BRACE, 期望 {); while (!check(TokenType.RIGHT_BRACE) !isAtEnd()) { parseStatement(); } consume(TokenType.RIGHT_BRACE, 期望 }); } finally { currentScope savedScope; } }try-finally在这里不是矫枉过正。一旦parseStatement内部遇到左括号缺失、分号缺失这类语法错误很多手写解析器会直接 return 或抛出跳过错误如果没有 finallycurrentScope就停留在子块的表上之后的解析全都在错误的作用域里查找符号报错行号全部漂移。你可以在自己的代码里故意去掉 finally用 sectionnef 的嵌套用例跑一遍会看到未声明错误的数量瞬间爆炸。这就是“作用域泄漏”的经典表现。4.4 函数调用检查参数个数与类型逐一比对函数调用是 sectionnef 实验里最容易丢分的地方因为它同时涉及声明和调用两个位置的信息。解析实参列表时先把每个实参的类型算出来放进一个临时列表再和符号表里函数声明时保存的paramTypes做比对private void checkCallExpr(Token callee, ListType argTypes) { Symbol sym currentScope.lookup(callee.lexeme); if (sym null) { reporter.error(callee.line, callee.col, 未声明标识符 callee.lexeme); return; } if (sym.paramTypes null) { reporter.error(callee.line, callee.col, callee.lexeme 不是函数不能调用); return; } if (sym.paramTypes.size() ! argTypes.size()) { reporter.error(callee.line, callee.col, 函数 callee.lexeme 实参个数不匹配期望 sym.paramTypes.size() 实际 argTypes.size()); return; } for (int i 0; i argTypes.size(); i) { if (argTypes.get(i) Type.ERROR) { continue; } if (!canAssign(sym.paramTypes.get(i), argTypes.get(i))) { reporter.error(callee.line, callee.col, 第 (i 1) 个实参类型不匹配期望 sym.paramTypes.get(i) 实际 argTypes.get(i)); } } }canAssign在这里承担了统一职责实参类型符合形参类型或者能隐式转换就算通过。还有一个容易漏掉的细节checkCallExpr只负责比对真正把实参类型列表汇总起来的是调用点解析逻辑。你在解析foo(a, b, c)时需要一次parseExpression得到类型、检查逗号、再parseExpression直到遇到右括号然后把收集到的ListType交给checkCallExpr。5. 语义分析常见翻车现场五个坑与对应的排查手法5.1 坑一重复声明把外层变量误伤现象内层块声明了和外层同名变量你的语义分析器报“重复声明”但 sectionnef 预期这里不报错。原因重复声明检查用了lookup它会顺着作用域链往上找导致外层已有的同名符号被判成旧声明。作用域规则里有一条叫“遮蔽”shadowing内层声明同名变量是合法的只是在内层作用域内外层变量不可见。解决把检查方法改成lookupLocal。拿到prev为 null 再确认lookup的结果非 null就可以发出“此符号遮蔽了外层符号”的 warning而不是 error。如果实验判分器只看 error 数量warning 多几个没关系但 error 多一个就会挂。5.2 坑二作用域弹栈时机不对导致符号表错位现象函数体解析完后后续代码里所有变量都报“未声明”或者反过来出了大括号还能查到块内局部变量。原因很多人把恢复旧作用域的代码写在方法末尾但解析出错时提前 return弹栈逻辑没执行。或者弹栈位置写在了consume(RIGHT_BRACE)之前花括号本身还没消费完就恢复旧表导致最后一个符号仍留在新表里。解决用try-finally包住整个块解析过程finally里无条件恢复currentScope。排查方法是打印每次进入和退出块的 scope 深度看栈是否对称。我一般会在parseBlock的入口打debug(enter scope depth depth)出口打debug(leave scope depth depth)一眼就能看出少了哪次弹栈。5.3 坑三错误恢复太激进导致级联错误刷屏现象x 1 ;这一行里sectionnef 预期报 1 个错误你的分析器报了 4 个后面所有语句连坐。原因解析到缺失的操作数时直接抛异常整个表达式返回ERROR但错误恢复机制把几行之后的表达式也误当成同一个表达式的一部分。或者反过来遇到错误后没有把表达式状态清掉循环里继续用旧的left类型参与比对。解决在表达式错误处返回Type.ERROR并且在二元运算循环里遇到LEFT ERROR || RIGHT ERROR时跳过运算符检查。这是“错误传播”的阻断策略。你还要给每个 parse 方法一个“同步点”分号或右括号是同步Token遇到它们就退出当前层回到语句层继续解析。5.4 坑四类型检查把隐式转换的一边给写反了现象float f 1;被报错而int x 1.5;反而通过。原因canAssign的规则写成了target actual或者target INT actual FLOAT把宽松方向和严格方向搞反。很多教学语言的规则是int 可以自动提升为 floatfloat 不能自动降级为 int。解决把类型决策表做成一个二维数组或者嵌套 switch测例里单独准备一组“合法转换”和“非法转换”的输入。如果你不确定 sectionnef 采用的是哪种规定就看实验文档里的分数分布凡是涉及 float 初始化 int 的用例几乎都对应这条规则。建议在canAssign里加一个boolean strictMode参数方便跑两套测试。5.5 坑五函数声明顺序导致“声明在后调用在前”误报现象sectionnef 输入里函数f定义在main后面但main里先调用了f你的分析器报“未声明标识符 f”实际预期是通过。原因递归下降是单趟扫描按源码顺序处理。如果实验要求允许前向引用单趟处理必然会误报。这也是语义分析从“一趟”变成“两趟”的标志性场景。解决常见做法是先做一趟预扫描只收集所有函数声明把函数名和签名填入全局符号表第二趟才做主体分析。预扫描阶段不用解析函数体只需要读到函数名和形参列表就停。如果你不想引入两趟就允许调用时的lookup失败后去函数声明表里查但这样代码会变脏我建议还是老实写两趟。6. 验证你的语义分析器从负向用例到对拍一套可执行的自检流程语义分析器的验证不能只靠“跑通程序”。它给的是判定结果验证的核心是负向测试——确保每个错误用例都报错、每行报错都出现在预期位置。我会把测试用例分成tests/ok/和tests/fail/两个目录然后用一个 shell 脚本自动做断言#!/bin/bash fail_count0 for src in tests/ok/*.sec; do if java SectionNef $src 21 | grep -q error; then echo FAIL: $src 预期通过但报了错误 fail_count$((fail_count 1)) fi done for src in tests/fail/*.sec; do if java SectionNef $src 21 | grep -q error; then : else echo FAIL: $src 预期报错但没检测到 error fail_count$((fail_count 1)) fi done if [ $fail_count -eq 0 ]; then echo all semantic tests passed else echo $fail_count tests failed exit 1 fi这个脚本只检查正向输出和负向输出属于半自动验证。更严格的做法是给每个fail/用例配一个.expected文件里面按行存“行号:错误类型”然后让 Java 程序输出到临时文件后逐行比对。注意比对时不要直接比grep error后剩下的内容要把错误消息格式固定成行:列: error: 描述这样自动评测才不会被中文描述差异干扰。我最后想留一个具体的自检清单你可以照着补测试用例第一类是只声明不初始化第二类是重复声明夹着多层作用域第三类是 int 转 float 的合法与非法边界第四类是函数调用参数多一个少一个各备一条。这四类用例跑通sectionnef 的语义分析基本就稳了。我自己的习惯是把这些用例当成“后悔药”每次改完代码先跑一遍全量测试再对着一次失败的输出调行号而不是靠眼睛扫描控制台。希望帮到你。本文还有配套的精品资源点击获取