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

Enable type parameter traversal in exact type patterns #222

Merged
merged 7 commits into from
Apr 12, 2024
Merged

Conversation

kriegaex
Copy link
Contributor

Closes #221

@kriegaex kriegaex linked an issue Jan 30, 2023 that may be closed by this pull request
@kriegaex kriegaex self-assigned this Jan 30, 2023
@kriegaex kriegaex added the enhancement New feature or request label Jan 30, 2023
Closes #221

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fixes #211. Previously, '?' was not converted to '*' in
UnresolvedType.nameToSignature, but kept as-is. That is why - falsely -
it was necessary to handle the '?' case in UnresolvedType.forSignature
at all, reading this kind of bogus signature and creating a type for it
in TypeFactory.createTypeFromSignature. This, ironically, led to correct
JVM generic type signatures containing '*' not being handled at all.

The conversion should now work correctly both ways.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Due to the latest improvements, an error which was previously not thrown
unexpectedly according to a source code comment in test aspect
ParameterizedTypesInAnnotationPatterns.aj is now thrown for this kind
of pointcut:

  staticinitialization(@(Foo || List<String>) String)

Now the compiler correctly says:

  no static initialization join points for parameterized types,
  use raw type instead

Relates to #221.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Upon meta annotation usage in signature patterns, lint warnings like the
following were issued during type parameter traversal:

  does not match because annotation @java.lang.annotation.Inherited
  has @target{ElementType.ANNOTATION_TYPE} [Xlint:unmatchedTargetKind]

To avoid this, we now heuristically check if we are in a meta annotation
situation and, if so, permit it.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Method visit(WildAnnotationTypePattern, Object) used to descend into
node.getTypePattern().accept(this, data), which since commit 6585b9e
is unnecessary, because WildAnnotationTypePattern::traverse already
traverses its type pattern.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
@kriegaex kriegaex marked this pull request as ready for review April 12, 2024 12:09
@kriegaex kriegaex added this to the 1.9.22.1 milestone Apr 12, 2024
@kriegaex kriegaex merged commit 2b5c498 into master Apr 12, 2024
4 checks passed
@kriegaex kriegaex deleted the gh-221 branch April 12, 2024 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enable type parameter traversal in exact type patterns
1 participant