为什么 Perl v5.22 找不到所有的句子边界？

Question

这在Perl 5.22.1中得到了修复。我在Perl v5.22中写过它，它添加了花哨的Unicode单词边界。

<小时 />

Perl v5.22 添加了来自 TR #29 的 Unicode 断言。我一直在玩句子边界断言，但它似乎只找到了文本的开头和结尾：

use v5.22;
$_ = "See Spot. (Spot is a dog.) See Spot run. Run Spot, run!x{2029}New paragraph.";
while( m/b{sb}/g ) {
    say "Sentence boundary at ", pos;
    }

输出在文本的开头和结尾注明句子边界，但不在句号、句子终止符或参数之后：

Sentence boundary at 0
Sentence boundary at 70

Unicode 中断测试器主要基于 TR #29 显示它们，我希望它们。

我在 perl 源代码中找不到此功能的任何重要测试。我正在消化技术报告以创建适当的测试用例，但到目前为止，这看起来像是另一个未经测试和损坏的功能。

Answer 1

Calle Dybedahl的评论是正确的（当他们把它变成一个答案时，我会接受）。这是 v5.22.0 中的一个损坏功能，据我所知，未经测试。昨晚我在编译最新的perls时遇到了一个问题，并以这个问题结束了一天。

perl5.22.1 perldelta 没有提到特定的更改（"提及"可能太强烈了，因为它只是暗示了可能出错的事情，而没有列举它们）。它提到与 5.20.0 不兼容的更改（剪切和粘贴错误？），一个"单一"异常，然后是多个问题。提到"理智"让我认为所有的变化都与下一节中的恐慌问题有关。提到只有一个 rt.perl.org 参考的"几个错误"让我认为这些错误与恐慌问题有关。

=head1 不兼容的更改

除了 以下单一例外，我们认为这是一个明智的更改 为了获得新的 C<\b{wb}> 和（特别是）C<\b{sb}> 功能理智 在人们因为Perl 5.22.0中的错误而认为他们一文不值之前 实施并避免将来使用它们。 如果存在任何其他错误，则它们是错误，我们要求您提交报告。 见下文L。

=head2 边界检查构造

几个错误，

包括分段错误，已经通过边界修复 check constructs （在 Perl 5.22 中引入） C<\b{gcb}>， C<\b{sb}>， C<\b{wb}>， C<\B{gcb}>， C<\B{sb}>， and C<\B{wb}>. 所有 C<\B{}> 现在都匹配一个空 字符串;C<\b{}> 的都没有。 L<[perl #126319]|https://rt.perl.org/Ticket/Display.html?id=126319>

此外，记录新边界的 perlrebackslash 没有提到它们在 v5.22.0 中不起作用。

由于 perldelta 中的不一致以及我之前的经验，我忽略了可能的修复程序，即新功能没有在 perl 源代码中充分（甚至根本没有）测试。我过早地切断了这条调查线，本可以节省几个小时。没有让代码在最新的二进制文件上运行当然是我的错，但我开始执着于我做错了什么并且我的代码是问题的想法。尽管我过去有很多相反的经验，但我并没有娱乐的想法（除了对ucd的更新）perl是错误的。

现在我在另一台机器上并且有一个工作的perl-5.22.1，我看到我的程序在点版本中按预期工作。这里的三角洲本可以好得多。

Answer 2

这种情况主要归咎于我，但还有其他人参与其中，所以我将在下面的地方使用复数第一人称。

首先，5.22.1 的 perldelta 表示 5.20.0 表示 5.22.0，这是一个错字。 它只提到了一个问题，因为在我们看来，它们只是一回事，Unicode打破了界限。

这些是在 5.22

后期添加的，直到 5.22 发布后我们才意识到存在问题。 当问题开始出现时，其中一些被证明是Unicode指定算法中的错误，我们假设所有这些都是这样的。

但一切都经过了测试，我想，足够广泛。 最近的 Unicode 版本包括发布各种功能的测试，5.22.0 通过了所有这些测试。 你可以在lib/unicore/TestProp.pl中找到它们，每次完成"make test"时都会运行，由t/re/uniprops.t执行。 这里所讨论的测试由 Test_SB（）（超过 500 个）和 Test_WB（）（近 1500 个）调用，每个测试由几个子测试组成。 这些测试比我自己想出来的要多。

独立地，有人在 5.23 开发过程的早期报告了段错误。 在调查时，我通过代码读取看到刚刚发布的代码中还有其他问题。 相互作用很复杂，不容易总结，所以perldelta甚至没有尝试。 这两种边界条件都需要跟踪边界可能发生的背景，通常是前瞻和/或后视。 当代码分析目标字符串时，它会为下一次迭代保存当前上下文，在该迭代中，它将是后瞻上下文，并且不必重新计算。 这被破坏了，上下文并不总是得到正确保存。 这就是为什么Unicode提供的测试都通过了。 它们用于短输入，上下文中断无关紧要。 当这一切得到解决时，我惊喜地发现 \b{sb} 给出的结果更符合人类的预期。

Unicode 错误计划在下一版本的 UAX #29 中修复，我认为我们在 5.22.1 中使 \b{wb} 和 \b{sb} 工作做出了正确的决定。