Open khatchad opened 6 years ago
My guess is that the entry point class we are using in WALA doesn't or improperly overrides the Object.equals()
method such that two entry points with the same method signature are not considered equal. The problem is probably in the WALA code.
First step should be to reproduce the problem by making a JUnit test case using a entry_points.txt file that has lines consisting of the same method signature.
In the results.csv file, you'll see the entry point count.
First step should be to reproduce the problem by making a JUnit test case using a entry_points.txt file that has lines consisting of the same method signature.
I cannot reproduce it.
My test case is:
package p;
import java.util.HashSet;
import edu.cuny.hunter.streamrefactoring.annotations.*;
class A {
void m() {
HashSet h1 = new HashSet();
h1.stream().count();
}
}
My file content is:
p.A.m()V
p.A.m()V
, but I only got 1 entry points in the result.csv.
I guess the hashset already made the distinct entry points.
This is not a bug. I suggest to close it.
I am still seeing it. To reproduce, annotate a method with @EntryPoint
(don't use entry_points.txt
) that would also be picked up by the implicit flags (e.g., annotate the main() method and turn on implicit entry points). In this situation, you'll have the same method explicitly marked as an entry point as well as implicitly.
From the logs, it looks like our tool has no problem using duplicate entry points, i.e., entry points represented by the same method. This can throw off our entry point count in the situation where we use both implicit and explicit entry points, or if duplicate entry points exist in the file (related to #172).