Fix #776: do not narrow access bounds of overriden methods in ParamForwarding

[DarkDimius]

No description provided.

[DarkDimius]

/rebuild

[DarkDimius]

paramForwarding.scala used to pass as we generated under-specified bytecode(private method overriding public one) that happened to work. Now we need to have a correct fix.

[DarkDimius]

for class

class A(val theValue: Int) {
}

class NonVal(theValue: Int) extends A(theValue) {
  def getTheValueInNonVal = theValue // use the constructor parameter theValue
}

before change we had:

public class NonVal
extends A {
    public NonVal(int theValue) {
        super(theValue);
    }

    @Override
    private int theValue() {
        return super.theValue();
    }

    public int getTheValueInNonVal() {
        return this.theValue();
    }
}

note @Override private. This lead to this.theValue being statically resolved to private method.
Additionally, it ment that in some callsites calling theValue on nw13 would lead to IllegalAccessError.

After change we have

public class NonVal
extends A {
    public NonVal(int theValue) {
        super(theValue);
    }

    @Override
    public int theValue() {
        return super.theValue();
    }

    public int getTheValueInNonVal() {
        return this.theValue();
    }
}

Note that method is now public, making it vulnerable to overriding in sublasses:

class X(override val theValue: Int) extends NonVal(0)

What scalac does in this case is this:

public class NonVal
extends A {
    public NonVal(int theValue) {
        super(theValue);
    }

    public int getTheValueInNonVal() {
        return super.theValue();
    }
}

As you see, it does not generate the method. I believe that this also supports my claim that method name is irrelevant.

Unfortunately, scalac approach cannot be implemented in a miniphase. What I propose instead is to create private method with a mangled name. I'll experiment with this.

[DarkDimius]

Closing in favor of #786.