Handle implicit calls from interface or superclass

[LoiNguyenCS]

Professor,

This is the PR to create synthetic interfaces and superclasses when methods from them are implicitly called.

Please take a look. Thank you.

[LoiNguyenCS]

The CI fails at the evaluation script step. I am not sure why. This discussion in this GitHub issue seems to be suggesting that we have reached the CPU limitations.

[kelloggm]

The CI fails at the evaluation script step. I am not sure why. This discussion in this GitHub actions/runner-images#6680 seems to be suggesting that we have reached the CPU limitations.

This is almost certainly a resource limitation issue on GitHub's side: our job is using too many resources, so it is being cancelled. We need to either reduce the amount of work that Specimin does, parallelize this job, or split up the evaluation job into multiple parts.

@LoiNguyenCS I know you've said you have some ideas about improving Specimin's performance by reducing the amount of I/O that it does. I think this problem is a good incentive to spending an hour or two investigating whether there is an easy win there.

@tahiat have you made any progress looking into parallelizing the evaluation of these builds using pash, as we discussed a few weeks ago? If we can land that, it would probably fix this problem, too.

[tahiat]

Professor, let me look into parallelizing using Pash today. I have not made any progress on that task.

[LoiNguyenCS]

Professor,

I have updated the code based on your review. Please take a look. Thank you.

[LoiNguyenCS]

Professor,

I have updated the codes. Please take a look. Thank you.

[kelloggm]

LGTM now, thanks

[LoiNguyenCS]

Professor,

Should we merge this PR or wait until we get the CI failure solved?

[kelloggm]

Should we merge this PR or wait until we get the CI failure solved?

Let's disable the evaluation script in CI (in this PR is fine) so that CI stays green.

[LoiNguyenCS]

I have temporarily disabled the evaluation script.

[kelloggm]

@LoiNguyenCS Sorry to bring this up now, when this has already been merged, but I don't think that this logic is correct. In particular, it fails to take into account subtyping: it is legal to call a method with arguments that are subtypes of the declared types of the method, but this method will return false in that case. For example, consider:

class A {}
class B extends A {}

class C {
   void test(A a) { ... }
...
   test(new B());
}

The call to test(new B()) is legal and typechecks, but this method would miss that this call is to a method defined in the class. The problem is that the argument and parameter lists don't exactly match up - each argument is a subtype.

I'm unsure if this is causing any of our problems (I observed it while debugging #152, but it is not the proximate cause of that issue I don't think), but we need to come up with a strategy to handle this case properly.