Fix: Patch file finding algorithm

Because commit 5c36c119f9448baf6bfe5245c6ebac1aa09d5b43 was not enough and was
actually buggy, this fixes the patch-file-finding algorithm _again_.

The approach changed a bit. It actually introduces even more overhead to the
loading algorithm, because of constant type-conversions. But it's as good as it
can be right now.

So first of all, we're collecting the patches before the merge into a
Vec<PathBuf>.  Each of those are existing.

Then we check whether the new patch exists, and if it not does, we check whether
the file actually exists in the patches from before the merge (by filename). If
it does, it seems that we dragged the entry from the previous recursion. In
this case, the patches from before the merge were valid, and the recursion
invalidated the path.

I.E.:

    /pkg.toml with patches = [ "a" ]
    /a
    /sub/pkg.toml with no patches=[]

in the recursion for /sub/pkg.toml, we get a ["a"] in the patches array, because
that's how the layered configuration works.
But because the path is invalid, we check whether before the merge (so, the
patches array from /pkg.toml) has a file named equally - which it does. So the
array before the merge is the correct one.

I did some tests on this and it seems to work correctly, but more edge-cases may
exist.

Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
Fixes: 5c36c119f9448baf6bfe5245c6ebac1aa09d5b43 ("Fix: Error out if a patch file is missing")

0 files changed, 0 insertions, 0 deletions