flex块注释规则详解：状态机、起始条件与错误恢复实践

写词法分析器的时候块注释block comment是看起来最简单、实际上一写就翻车的东西。我最近用flex给一个类C语言做前端第一版块注释规则就写了三行正则结果一跑注释后面的整个文件全被吞了。flex不像手工递归下降那样可以一行一行盯着看它有自己的匹配哲学最长匹配优先、规则顺序优先遇到/*到*/这种跨行结构如果不引入状态管理任何朴素写法都会出问题。这篇文章把flex里块注释规则的原理、经典写法、嵌套支持和错误恢复全部拆开讲清楚附带可以直接抄走的完整.l模板。适合正在写编译器前端、做代码静态分析、写grep风格扫描器或者刚接触flex想弄明白状态机的同学参考。1. 块注释为什么是词法分析里最容易被低估的一环1.1 注释不是“删掉就好了”的字符串很多人写lexer时注释的优先级排在最后心里想的是“反正注释内容不影响语义匹配到就跳过”。这个想法本身没错但实际操作时块注释和行注释完全是两个难度等级。行注释从//到行尾规则非常简单一个正则就能收掉。块注释却是跨行的从/*开始一直到*/结束中间可能有几十行、几百行内容还可能被字符串字面量里的/*干扰甚至某些语言还允许嵌套。块注释真正的难点在于词法分析器是流式的它不知道自己现在处于什么上下文。看到/*之后接下来的所有字符都不能当作普通代码处理直到遇到*/。这就是一个状态切换问题。flex支持所有正则的串接但正则本身没有“记忆”一个/*到*/的匹配范围需要用状态机来维护而不是靠一条复杂的正则硬扛。所以与其说块注释规则是正则怎么写的问题不如说它是lexer状态设计的问题。理解了这一点后面所有细节都好说。1.2 flex的匹配哲学最长匹配与规则优先级在写具体规则之前必须把flex的两条匹配铁律刻在脑子里。第一条flex扫描时会在所有能匹配当前输入的模式里选择匹配字符最长的那个。第二条如果多个模式匹配的字符串长度相同则选择写在前面的那个模式。这两条规则决定了块注释和其他规则之间的先后顺序。举个例子输入是/* not comment */如果字符串字面量规则和块注释规则同时都能匹配但字符串规则能匹配完整的一整个带引号字符串长度远比/*到后面某个位置更长flex就会优先走字符串规则这样字符串里的/*就不会被当成注释开头。反过来如果块注释规则写在前面而字符串规则定义得不完整一旦遇到字符串里包含/*flex可能错误地进入注释状态。所以规则的顺序不是随便排的关键字、标识符、数字、字符串、注释、操作符每一类都得有清晰边界。通常建议把字符串字面量规则放在块注释规则之前或者用起始条件隔离避免两者冲突。2. 不用状态怎么写都会翻车起始条件入门2.1 最朴素的写法为什么会吞代码很多新手写出第一版块注释规则是这样的/*([^*]|[^*][*]**/)**/ { /* skip */ }或者更偷懒/*.**/ { /* skip */ }先说第二种。.*在flex里默认匹配除换行符以外的字符所以这条规则只对单行内以/*开头、以*/同一行结尾的情况有效。一旦遇到跨行注释立刻失效。第一种试图用一个巨大的正则描述“注释内容结束标记”正则本身可以工作但可读性和可维护性都很差而且它有一个隐蔽问题flex默认按最长匹配挑规则这种超大正则经常会把后面一大段代码也卷进来。比如输入/* comment */ int a 1;如果正则写得不够精确flex可能会从/*一直匹配到后面的某个*/为止中间即使已经走到了int a 1;也被当成注释内容吞掉。这种问题调试起来很痛苦因为报错位置和实际出错位置往往差了几百行。2.2 起始条件start condition解决状态问题正确的思路是把“在注释里”当成一种独立的词法状态。flex提供了起始条件start condition机制用%s或%x声明然后在规则前面用尖括号指定规则生效的状态。声明方式%x COMMENT%x的意思是“排他性起始条件”一旦进入这个状态所有未带状态标签的普通规则都不会生效只有COMMENT开头的规则会被扫描。这正是我们想要的进入注释后代码里的标识符、数字、关键字规则全部失效lexer只关心注释内容的出路。进入和退出注释状态的规则/* { BEGIN(COMMENT); } COMMENT*/ { BEGIN(INITIAL); }INITIAL是flex内置的初始状态BEGIN(COMMENT)负责切换。这一组规则解决了核心状态流转接下来要处理的是注释内部“逐字符还是成块匹配”的问题。2.3%x和%s的区别以及块注释该选谁flex支持两种起始条件%x是排他的%s是包含的。%s状态下普通规则依然参与匹配%x状态下普通规则完全不参与。块注释必须用%x没有例外。如果误用了%s会出很有意思的问题进入注释状态后规则int、[a-zA-Z_][a-zA-Z0-9_]*、数字正则等仍然有效遇到注释里的文本可能被匹配成标识符或关键字完全乱套。%s一般只在那些“需要同时开启一些通用规则”的场景使用比如HTML模板里混合普通文本和标签时。块注释是一个完全隔离的空间里面不应该有任何代码规则%x是唯一正确选择。3. 块注释规则的经典实现与完整模板3.1 教科书级的注释规则长这样flex手册里有一个经典的块注释写法简洁高效强烈建议直接抄%x COMMENT %% /* { BEGIN(COMMENT); } COMMENT[^*]* { /* skip non-* characters */ } COMMENT*[^*/]* { /* skip * not followed by / */ } COMMENT*/ { BEGIN(INITIAL); }拆开看这三条注释内部规则。第一条COMMENT[^*]*匹配所有不是*的字符能连续吃下一大段普通注释文本。注意[^*]不包含换行符所以跨行问题后面还要补一条\n处理。第二条COMMENT*[^*/]*处理“星号但不是注释结束”的情况。注释内容里经常有连续的星号比如画分隔线用的******如果把*交给第三条规则一旦后面跟的不是/就会出现匹配失败flex会退回到更短匹配或者产生错误。所以这一条先把“一串星号且后跟非斜杠字符”全部消化掉。第三条COMMENT*/匹配真正的注释结束标记。因为flex最长匹配优先遇到****/这种连续星号加斜杠时第三条会匹配最长的那一串星号和末尾的/正确结束注释。这个写法的好处是大部分注释内容一次消费一大块而不是一个字符一个字符地扫性能上比COMMENT.好很多。但注意这三条规则共同的问题是没有显式处理换行符。[^*]和[^*/]都不会匹配\n所以跨行注释会在换行符上卡住。需要补一条COMMENT\n { /* do nothing, maybe count lines */ }如果需要统计行号可以在这里处理COMMENT\n { yylineno; }如果你在%option里开了yylinenoflex会在每次遇到换行时自动计数上面的手动累加可以省略。但开不开yylineno会影响后续错误定位建议一开头就加上%option yylineno并且弄清楚它的计数时机。3.2 带嵌套注释和错误恢复的完整lexer实例有些语言不支持嵌套注释C语言就不支持但很多脚本语言和配置格式支持。如果你写的lexer面向的是类C风格又希望支持嵌套事情就变得有点意思。支持嵌套的关键是记录注释深度。进入/*时深度加一遇到/*继续加一遇到*/深度减一直到深度归零才退出注释状态。一个可用的规则模板%option noyywrap yylineno %x COMMENT %% /* { if (comment_depth 0) comment_start_line yylineno; comment_depth; BEGIN(COMMENT); } COMMENT/* { comment_depth; } COMMENT*/ { if (--comment_depth 0) BEGIN(INITIAL); } COMMENT[^*\n] { /* skip text */ } COMMENT*[^*/]* { /* skip stars not followed by slash */ } COMMENT\n { /* line is counted automatically by yylineno */ } COMMENTEOF { fprintf(stderr, unterminated comment starting at line %d\n, comment_start_line); return -1; }COMMENTEOF是flex的EOF规则只有在文件结束且当前处于COMMENT状态时触发。这里的comment_depth和comment_start_line需要在lexer外面定义是全局变量或lexer类的成员。这样未闭合注释不会在flex层面直接崩溃而是得到一行清晰的错误信息。这里有个细节嵌套注释用的COMMENT/*必须写在COMMENT[^*\n]前面。因为flex对同一状态的规则也是按最长匹配优先但可能长度相同所以越具体的模式越要靠前。/*和[^*\n]如果匹配长度相同先写谁谁赢。3.3 别忘了行号跨行注释与yylineno调试词法分析器时最怕的不是语法错而是报错行号完全对不上。块注释是行号错乱的常见来源。如果不开yylinenolexer本身不维护行号所有错误定位都没有意义。开了之后flex在内部每次读到\n会自动递增yylineno不需要你在规则里手动yylineno但必须注意yylineno计数的是flex实际读取的换行符而不是规则匹配后的文本。如果某条规则里用.匹配了不包含换行的内容没事但如果用[^\n]*显式吞掉换行符又没走\n规则yylineno依然会递增因为flex在扫描引擎层面计数不受具体规则影响。跨行注释的行号统计最稳妥的写法是开着%option yylineno然后在注释内容规则里让换行符正常经过扫描。COMMENT\n这条规则本身可以留空也可以打印调试信息。不要在注释整体匹配进去后再手工数里面的换行次数那样容易重复计数。在我自己的项目里注释开始行始终记录在comment_start_line注释里如果发生错误比如嵌套深度异常或EOF未闭合报告行号直接用这个变量。如果没有它遇到未闭合注释你能得到的只有文件末尾行号对解决问题毫无帮助。3.4 和字符串字面量、正则字面量怎么和平共处块注释规则最经典的冲突对象是字符串字面量。看这个输入const char *url http://example.com/* not a comment */;字符串里包含了/*和*/。如果lexer只有块注释规则扫描到http:后面的//可能没事但一旦遇到/*如果按照规则顺序flex会尝试进入注释状态。字符串规则必须能和块注释规则竞争。字符串规则的推荐写法是\([^\\\]|\\.)*\ { /* handle string literal */ }这个正则匹配一个完整的字符串包括转义符\。因为普通字符串字面量的长度从第一个引号到最后一个引号一定大于字符串内部的/*到后面某处按照最长匹配原则flex会优先选择字符串规则整段吃掉注释规则根本没有机会触发。但有个前提字符串规则必须写在块注释规则前面。如果块注释写在前面且两者能匹配相同长度先出现的规则就会获胜注释规则可能会抢在字符串前面。这是flex规则顺序的坑记住就好。类似的问题也出现在正则字面量、模板字符串、原始字符串上。凡是引号包裹、内部又可以包含/*的语法都必须保证对应规则能匹配完整结构并且排在块注释规则之前。4. 块注释规则常见翻车现场与排查清单4.1 注释吃掉后面的token症状一段正常代码从某个注释开始后面的关键字、变量名全都不见了输出结果里只有一堆空白或者解析器报错“unknown character”。排查方向先在注释规则后面加一个临时的调试动作把注释内容打印出来比如COMMENT[^*\n] { fprintf(stderr, comment: %s\n, yytext); }看看实际被匹配的范围到哪。绝大多数情况是结束规则没写对COMMENT*/和COMMENT*[^*/]*的顺序反了导致*/被第二条匹配消耗掉flex永远等不到结束标记。还有一个容易忽略的点*/必须写成字符串形式不要写成\*\/或字符类[*/]。我见过有人把结束规则写成COMMENT[*]/这会匹配“任意一个星号后跟斜杠”逻辑上没错但[*]和*有细微差别前者是字符类匹配一个星号后者是字符串字面量匹配一个星号。两者在简单场景下等价但写清楚更保险。4.2 未闭合注释导致文件尾报错症状文件末尾报错说遇到了意外的EOF但源码里每个注释看起来都闭合了。或者反过来源码确实有一个注释忘了闭合报错位置却指向文件最后一行根本看不出是哪个注释的问题。解决方案就是前面说的COMMENTEOF规则。记录注释起始行的变量很关键COMMENTEOF { fprintf(stderr, error: unterminated comment started at line %d\n, comment_start_line); return -1; }没有EOF规则时flex遇到EOF会调用yyterminate()当前注释处理到一半就结束后续逻辑完全不可控。有了这条规则至少能拿到正确的起始行。另一个细节如果你用的是%option yylinenocomment_start_line的记录必须在进入COMMENT状态之前完成。因为BEGIN(COMMENT)之后yylineno还会继续增加等你发现错误时它已经指向文件末尾了。4.3 嵌套注释引发的状态错乱症状代码里写了嵌套注释lexer在第一个*/就开始退出注释导致第二个/*到后面的代码全部被当作普通代码产生一堆莫名其妙的语法错误。这就是不支持嵌套的lexer遇到嵌套注释的典型表现。C语言本身不支持嵌套注释所以这种输入本来就是非法代码但真实项目里会有各种方言比如某些编译器的/*/* nested */ still in comment */是允许的。如果你决定支持嵌套用计数器是最稳的。注意计数器加一和减一的位置不要写反/* { if (depth 0) start yylineno; depth; BEGIN(COMMENT); } COMMENT/* { depth; } COMMENT*/ { depth--; if (depth 0) BEGIN(INITIAL); }判断退出条件时一定要先减后判断。有些新手写成if (depth 1) BEGIN(INITIAL); depth--;这在非嵌套场景看着一样但遇到嵌套时会让第一次退出就回到初始状态内层注释还没结束就开始解析代码了。4.4 性能问题逐字符匹配为什么慢有朋友写过这样的注释规则COMMENT. { /* skip single char */ } COMMENT\n { /* skip newline */ }能工作但一旦注释块有几百行、几千行lexer会一个字符一个字符地推进被注释的内容越长速度越慢。在大型源码扫描场景下这种写法会让lexer慢到一个不可接受的地步。优化方向就是3.1里的成块匹配。COMMENT[^*\n]一次可以消费一整段普通文本COMMENT*[^*/]*一次可以消费一串星号加后续非斜杠内容。除非注释内容全是单个星号交替否则大部分时间都能做到一次匹配几十个字符。如果注释里还可能有Windows的\r\n换行把\r也考虑进去COMMENT[^*\r\n] COMMENT\r?\n { /* line counting handled */ }不然\r会落到哪个规则里去你可能半夜才能想明白。5. 我在项目里沉淀下来的几条块注释经验块注释规则写到现在我在多个lexer项目里踩过不少坑最后沉淀下来的经验大概是这几条。第一条永远不要试图用一条超长正则去匹配“从/*到*/的全部内容”。正则表达式的表达能力很强但lexer需要的不是表达力而是可调试性。状态机拆分越细发现问题时越容易定位。/*进状态内容逐段匹配*/出状态这个三件套最可靠。第二条字符串规则一定要写在块注释规则前面。只要你的语言里字符串、正则、模板字面量这些东西内部可能包含/*或*/顺序写错就是灾难。这不是flex的bug而是最长匹配和规则顺序共同作用的结果。把它当作固定顺序背下来字符串字面量规则在前关键字和标识符居中注释规则靠近后部但必须在单字符操作符之前。第三条错误恢复和行号统计必须在写规则的第一天就加进去不要等lexer写完了再补。不记录注释起始行的lexer在处理未闭合注释时只能给你一个没有任何线索的EOF错误。有了comment_start_line、comment_depth、yylineno不管是语法错误还是注释错误定位效率都会高很多。我在实际写一个代码统计工具时就靠这组规则处理过几万行的第三方源码期间遇到最典型的问题是http://example.com这类URL在注释外但被字符串规则漏掉的情况。当时字符串规则写的是\[^]*\没处理转义引号结果字符串里出现\时整个规则就断了后面的/*就被注释规则抢走。后来改成\([^\\\]|\\.)*\再配合规则顺序调整问题就消失了。块注释这件事看起来小但它牵扯出的是flex整个状态机设计思想。你把它研究透了后面写字符串、写模板语法、写预处理指令都会有章可循。希望这篇能让你少踩几个我踩过的坑。