The test case in this PR is based on the bug in #272, but this PR does not fix the infinite loop reported there. However, it does expose four smaller bugs that this PR does fix:
we didn't have a way to express that a synthetic class was an annotation
JavaTypeCorrect was splitting on spaces when parsing error messages and assumed that types would not contain a space. This isn't true if one of the types has type parameters or is a wildcard
TargetMethodFinderVisitor was not handling wildcard bounds properly, causing classes that were only used in wildcard bounds (like Annotation in the test case) to incorrectly be excluded from the output
type correction did not take into account wildcards at all. I added a special case for when both the type to correct and the new type are of the form Class<X> and Class<Y> that corrects from X to Y, but this could probably be generalized further.
The test case in this PR is based on the bug in #272, but this PR does not fix the infinite loop reported there. However, it does expose four smaller bugs that this PR does fix:
JavaTypeCorrectwas splitting on spaces when parsing error messages and assumed that types would not contain a space. This isn't true if one of the types has type parameters or is a wildcardTargetMethodFinderVisitorwas not handling wildcard bounds properly, causing classes that were only used in wildcard bounds (likeAnnotationin the test case) to incorrectly be excluded from the outputClass<X>andClass<Y>that corrects fromXtoY, but this could probably be generalized further.