Application of parchment can cause behavioral changes

[lukebemish]

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.