Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize type parameters #103

Merged
merged 4 commits into from
Feb 6, 2024

Conversation

LoiNguyenCS
Copy link
Collaborator

Professor,

This is the PR to remove unused type bounds of type parameters in the declaration of a class. After this PR and #101 are merged, Specimin will be able to minimize AnalysisResult.java.

@LoiNguyenCS LoiNguyenCS requested a review from kelloggm February 5, 2024 04:39
@LoiNguyenCS
Copy link
Collaborator Author

Professor,

I have updated the test case to remove one generic type bound and preserve the other type bound.

@LoiNguyenCS LoiNguyenCS requested a review from kelloggm February 5, 2024 23:20
Copy link
Collaborator

@kelloggm kelloggm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the new test case. LGTM!

@kelloggm kelloggm merged commit 1c8d153 into njit-jerse:main Feb 6, 2024
1 check passed
@kelloggm kelloggm deleted the update-class-thoroughly branch February 6, 2024 14:17
kelloggm pushed a commit that referenced this pull request Jul 25, 2024
This PR addresses an issue I found in [NullAway issue
#103](uber/NullAway#103), where compile-time
errors were caused by missing methods and types. The missing methods
were caused by the following:

**1) Methods not preserved**

Foo extends (abstract) Bar extends [Some JDK interface]

If Bar contains an abstract method also present in the JDK interface,
those implementations in Foo were removed while the abstract definition
was maintained in Bar, causing compile-time errors. A check was added to
ensure that all super abstract methods did not contain anything that
needed to be preserved (i.e. when in Foo, instead of just checking Bar,
we check Bar and the JDK interface).

**2. Classes not preserved**

If a non-target class needs its method implementations to be preserved,
and some of its return/parameter types are solvable but were untracked
so far by `usedTypeElements`, their ancestors were not preserved. For
example, if a method visited by `MustImplementMethodsVisitor` is of type
`PeekingIterator<E>` which extends `Iterator<E>`, the `extends
Iterator<E>` portion is kept in the original definition but its import
statement was removed, leading to compile-time errors. The new approach
to this is, if a type element was not previously in `usedTypeElements`,
all of its ancestors (interfaces and super classes) would also be marked
for preservation.

A test case can be found in `Issue103Test`.

Thanks!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants