Description Stephan Herrmann 2010-11-11 09:39:29 EST

After fixing bug 326969 it turns out that one specific kind of tsuper call
is wrongly resolved:

public team class Team0 {
	protected abstract team class TeamA {
		protected abstract class R {
			protected void print() { System.out.println("topR"); }
		}
		public void test() {
			System.out.println("topT");
			new R().print();
		}
	}
	
	protected team class TeamB extends TeamA {
		protected class R {
			protected void print() {
				System.out.println("0B");
				tsuper.print();
			}
		}
		public void test() {
			System.out.println("TeamB");
			super.test();
		}
	}
}
public team class Team1 extends Team0 {
	@Override
	protected team class TeamA {
		@Override
		protected class R {
			@Override
			protected void print() {
				System.out.println("1A");
				tsuper.print();
			}
		}
		@Override
		public void test() {
			System.out.println("TeamA");
			tsuper.test();
		}
	}
	public static void main(String[] args) {
		new Team1().test();
	}
	void test() {
		new TeamB().test();
	}
}

At the level of TeamB/TeamA the correct sequence is invoked:

  Team0$TeamB   -super-> Team1$TeamA   -tsuper-> Team0$TeamA

However, the nested role skips the middle step:

  Team0$TeamB$R            -tsuper->             Team0$TeamA$R

Difference is:

- Team0$TeamB.super actually considers the dynamic type of the
  outer team yielding Team1$TeamA

- Team0$TeamB$R.tsuper is statically resolved to TeamA$R without
  respecting the dynamic type of the outer team, thus targeting
  Team0$TeamA$R as determined by the static call site within Team0.


I fix should be made inside the logic for bytecode copy from
Team0$TeamB$R to Team1$TeamB$R (replacing also outer teams with
the current outer team).