Assigning a variable to this and calling an inaccessible method should fail #149
Labels
Milestone
Comments
|
A similar example with the Pull Up refactoring produces an error. Here's the input example: package p;
class I {
}
class A extends I {
void n() {
}
public void m() {
A a = this;
a.n();
}
}The error produced says that one of the methods is not accessible. |
|
But, as I thought, it also gives an error with this input where it shouldn't: package p;
class I {
}
class A extends I {
void n() {
}
public void m() {
A a = new A();
a.n();
}
}This is the same issue we had with #144. |
|
This is exactly https://bugs.eclipse.org/bugs/show_bug.cgi?id=241031. |
|
You need type constraints here to solve this problem. |
khatchad
pushed a commit
that referenced
this issue
May 17, 2016
Weird that the FIXME comment said that it should pass when in fact it was a passing test.
khatchad
pushed a commit
that referenced
this issue
May 17, 2016
khatchad
pushed a commit
that referenced
this issue
May 27, 2016
Forgot about constructor calls. Treated those as method invocations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks like my fixes from yesterday are actually not complete. Related to #144 and #141. Here's the example:
Before
After
Discussion
thisis no longer of compile-time type A but nowI. This (no pun intended) should be a situation taken care of by the Pull Up refactoring that we are building our refactoring on via type constraints, but I have a feeling that we'll have the same problem there as the Eclipse implementation of Pull Up does not seem to use type constraints for preconditions.-- Error Log from JUnit —
The text was updated successfully, but these errors were encountered: