正则表达式的语法检查和附录B

• 背景：有人开始在正则表达式上进行语法检查。
• 结果太脆弱了，太多有效的代码被拒绝了。
• 许多正则表达式利用了ECMAScript的"附录B"语法/行为。
• 什么是附录B?
• ECMAScript为网络浏览器编码了现实世界。
• 附录B有一整节用于扩展正则表达式中允许的内容。
• 允许
• 在look-arounds之后的量词
• 允许 ] 、 { 和 } 作为裸模式字符
• 当缺少控制序列时( \cb 是普通情况，但你有 \c ,它只是 c ,有点像身份转义)
• 身份转义是允许的( \a = a )
• 即使不存在反向引用(就像身份转义一样，只变成 \1 )
• 允许遗留的八进制转义
• 允许无效的字符类范围
• 这些在Unicode模式下不起作用。
• 其中一些是不好的 - 我们想无论如何都要对Annex B规则进行错误检查吗？
• 无效的模式字符 - /]{}/ ?
• 也许
• 身份转义？
• 很多东西似乎在使用只有其他正则表达式模式(如Unicode模式)才有的功能。
• 但人们经常主动转义标点符号。
• 也许只需要ASCII字母？
• 这似乎更好。
• 无效的反向引用？
• \2 - 人们通常希望这表示一个反向引用，但这将被解释为一个八进制转义！
• 在字符类中的反向引用？
• [\1] - 这是反向引用，但它在字符类中 - 它只是一个字符类中的八进制 1 。
• 当人们写 [^\1]+ 通常人们想要说 "除了第一个捕获之外的任何内容" - 但这实际上是 (?:(?!\1).) 。
• 无效的范围？
• 将字符类用作范围边界。
• /\w-_]/ 被视为与 /[-\w_]/ 相同。
• 错误的目标？
• 可能可以继续出错吗？人们可以使用一个 // @ts-ignore
• 我们可以为这些提供针对编辑器的特定建议诊断吗？
• 特别是像无效范围这样的东西。
• 这个不感觉像是噪音的大一部分。

--skipCheck / --noCheck

上次我们讨论了 skipCheck ,我们说我们会将其作为API-only功能暂时实现，因为没有办法围绕它提供用户场景。需要更多的思考。

• 我们是否应该禁止在启用 skipCheck 时生成 .tsbuildinfo 文件？
• 目前它不仅仅是API-only,而且是内部-only。
• 所以目前它只是
• 我们还有一个PR来阻止在外部传入的其他内部-only选项时生成 skipCheck 。
• 可能不需要对所有内部选项都这样做 - 主要问题是关于 tsbuildinfo 的行为。
• 但没有人可以传入这个选项。
• 问题陈述是什么？
• 我们是否需要做防御性检查以确保生成的是 undefined 而不是无效的 .tsbuildinfo ?或者它只能生成无效的 .tsbuildinfo ?
• 我们将在公共时解决这个问题。

严格只读

#58296