Application of parchment can cause behavioral changes #44
Description
In 1.21.4, the method body of DownloadCacheCleaner.listFilesWithModificationTimes looks something like this:
private static List<PathAndTime> listFilesWithModificationTimes(final Path p_314985_) throws IOException {
try {
// ...
Files.walkFileTree(p_314985_, new SimpleFileVisitor<Path>() {
public FileVisitResult visitFile(Path p_314922_, BasicFileAttributes p_315004_) {
if (p_315004_.isRegularFile() && !p_314922_.getParent().equals(p_314985_)) {
// ...
}
// ...
}
});
// ...
} catch (NoSuchFileException var2) {
// ...
}
}Parchment renames p_314985_ to path and p_314985_ to path; while JST contains checks that names to not match a local, it does not seem to check this type of inheritance of scope. Thus, the check !p_314922_.getParent().equals(p_314985_) becomes the nonsensical check !path.getParent().equals(path) check instead. This is enough of an edge case and a niche piece of code -- and it occurs only in dev -- that I doubt you would see any particular impact from this; however, similar cases could very well arise in the future, either due to vanilla changes or the introduction of more parchment mappings, and I am not sure how many such cases are present in MC and parchment currently; I only found this one because it resulted in a change in the descriptor of the ctor of DownloadCacheCleaner$1 (that anonymous class) between dev and prod, and I was investigating such descriptor shifts for other reasons.