sfPlayer1 / Matcher

Tool for tracking elements in obfuscated Java archives across releases
GNU General Public License v3.0
75 stars 41 forks source link

Interfaces no longer act as parents #10

Closed Chocohead closed 5 years ago

Chocohead commented 5 years ago

The new hierarchy changes have fixed the original issue with soft interface implementation, but in doing so appear to no longer count interfaces as parents to methods:

public interface ni {
    //Tmp name: ca409
    //Implemented by: aaw, aay, bm, ko, lh, nz, pt, rs, tr, yp 

    public int a();
    //Tmp name: vma9

    public void G_();
    //Tmp name: vma10
    //Previous had children in: aaw, ko, nz, pt, rs, yp
    //Now has no children

    //Snip
}

This however is not consistent between methods deeper in the class hierarchy:

public class rs implements ni {
    @Override
    public int a() {
        return 64;
    }
    //Tmp name: vma9
    //Child in z yet no parent

    @Override
    public void G_() {
        if (this.d != null) {
            for (int i = 0; i < this.d.size(); ++i) {
                ((jk) this.d.get(i)).a(this);
            }
        }
    }
    //Tmp name: vma10
    //No parents or children

    //Snip
}

class z extends rs {
    //Snip

    @Override
    public int a() {
        return 1;
    }
    //Tmp name: vma9
    //Parent in rs

    @Override
    public void G_() {
        super.G_();
        this.a.a(this);
    }
    //Tmp name: vma10
    //No parents
}

Despite this the naming is correct for all of them which is especially strange. Matcher doesn't seem to be affected by this to actually auto-match, but it does slightly hinder Merger as it relies on methods having interfaces as parents to guess if otherwise unreferenced interfaces are the same.

Chocohead commented 5 years ago

Think this was completely fixed with 91b7653.