我正在尝试重构一些代码。我的方法（使用vi）是将我的旧库从 /lib复制到 /lib2.这样我就可以破解大部分，但仍然有一个框架可以重构。
所以我继续将mymain. p6标头从use lib'…/lib'；更改为use lib'…/lib2'；。然后我删除中的一大块行…/lib2/my库.pm6并确保：w正在做我期望的事情。
想象一下我的惊讶，当我的程序仍然完美地工作，尽管已经被删除了很多。它甚至在我 /lib的时候也能工作，所以后面没有什么是持久的。
是否有可能我周围有旧lib模块的precomp？如果是，我如何刷新它？
这是Rakudo Star版本2019.03.1，基于MoarVM版本2019.03实现Perl 6. d。
预编译模块存储在precomp目录中。您可以尝试重命名或删除~/. precomp目录。
另请参阅此处的SO问题。
更新。我想我已经复制了这个场景。它可靠地显示了一小时内的bug。但现在不是了。这很令人不安。调查仍在继续…
我已经复制了@p6steve的场景，以防有人希望将此报告为bug。目前，我支持@p6steve（根据下面的评论），因为我将把它视为DIHWIDT，而不是可报告的bug。也就是说，现在我们有了一个高尔夫球的总结。
使用ath1的原始主程序，后跟它直接使用的模块，然后是使用：
use lib 'path1';
use lib1;
say $lib1::value;
unit module lib1;
use lib2;
our $value = $lib2::value;
unit module lib2;
our $value = 1;
这显示1。
如果lib被复制到一个新的目录，包括. precomp目录，然后lib2被编辑但lib1没有，则忽略对lib2的更改。
这是在复制库及其. precomp目录然后编辑库之前和之后的glot.io。
谢谢你编辑你的问题。这给了我们更多的线索。：）
我想试着弄清楚它的真相，希望你也愿意试一试。这个答案和下面的评论将记录我们的进展。
从你对@ValleLukas回答的评论来看：
然后我注意到…/lib2/. precomp目录-所以实现的库预编译存储在库文件夹中。这完成了工作！
这是我对发生的事情的第一个猜测：
您将lib整体复制到lib2。这复制了带有它的precomp目录。
您修改了mymain. p6中的use lib…语句以引用lib2。
您的mymain. p6代码包括一个use module-that-直接或间接使用-myLibrary。
您修改myLibrary. pm6。
但什么都没变！为什么不呢？
您还没有接触module-that-直接-或-间接-使用-myLibrary，因此Rakudo使用lib2/. precomp目录中该模块的预编译版本。
推测…
也许预编译版本存在的事实导致预编译逻辑假定，如果它也找到了module-that-直接-或-间接-使用-myLibrary使用的模块的预编译版本，那么它可以继续使用它，甚至不用费心检查它的时间戳与源版本的比较。
这是否符合您的场景？如果不是，它会出错哪些位？
