search

njit-jerse / specimin

SPECIfication MINimizer. A different kind of slicer for Java.
MIT License
0 stars 5 forks source link

Preserve constructors to solve compilation errors #220

Closed LoiNguyenCS closed 3 months ago

LoiNguyenCS commented 3 months ago

Professor,

This PR fixes the compilation error in cf-3022.

I think my comments and Javadoc are not clear. So I would greatly appreciate your suggestions.

Given a class with a constructor utilized by target methods (let's call it constructor A), if constructors from the super-classes of that class are also used by target methods, we need to ensure the preservation of the super(...) call within A. However, implementing this preservation strategy can be quite challenging. Therefore, I've opted to maintain the entirety of A's body.

To illustrate this point, consider the following scenario with the test case constructorrequirement: If we were to empty out the constructor of BazChild, we would encounter a compilation error similar to the one below:

@LoiNguyenCS ➜ /workspaces/specimin/tempDirOutput (fix-3022) $ javac com/example/*.java
com/example/Foo.java:5: error: constructor Baz in class Baz cannot be applied to given types;
    BazChild(String args) {
                          ^
  required: String
  found: no arguments
  reason: actual and formal argument lists differ in length
1 error

I would greatly appreciate your feedback on this approach. Please let me know your thoughts. Thank you.

LoiNguyenCS commented 3 months ago

In particular, it fails because the rest of preserved constructors should not be preserved - the super or this call must be, but the rest of the content can be deleted or replaced with throw new Error().

As explained above, just preserving the super() call is hard, since there could be local variables inside that super() call, which are defined somewhere in the same constructor. I think we can somewhat resolve this issue by removing every statement that appears after the super() call.

kelloggm commented 3 months ago

As explained above, just preserving the super() call is hard, since there could be local variables inside that super() call, which are defined somewhere in the same constructor. I think we can somewhat resolve this issue by removing every statement that appears after the super() call.

That's not the case: the grammar requires the super/this call to be the first statement in a constructor, if it exists.

LoiNguyenCS commented 3 months ago

That's not the case: the grammar requires the super/this call to be the first statement in a constructor, if it exists.

That's wonderful. Thank you. I will update the codes accordingly.

LoiNguyenCS commented 3 months ago

Professor,

Thanks to your insight, I have been able to simplify the codes. Please review again. Thank you.

LoiNguyenCS commented 3 months ago

I'm not sure why the CI is failing. Maybe something is wrong with the relevant Python script?

kelloggm commented 3 months ago

https://github.com/tahiat/specimin-evaluation/pull/25 was recently merged. I suspect that's the cause of the failure. @tahiat can you take a look at this failure and, if the cause is in fact https://github.com/tahiat/specimin-evaluation/pull/25, roll back ore revert that PR? Once you've done so, we can rerun CI here.