Comment on newly pointcut parsing found problem in test class
A pointcut like
execution(*..Collection<?>[] *(..))
leads to an AJ core dump, which is something I noticed while fixing a
test in the previous commit. I am going to create a new issue for it and
link to this commit later.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
After the changes, the weaver's behaviour is now slightly different, but
not actually buggy. Actually, in one case there is now a weaver warning
for a non-matching pointcut which should have been there before, but was
not. I.e., things have improved and the tests are even a bit better now.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix PointcutRewriterTest, add LogicalPointcutStructure test helper class
After WildTypePattern.hashCode was fixed in the previous commit,
PointcutRewriterTest started failing, because in many places it was
falsely relying on a specific order of hash codes, which cannot be
guaranteed, especially since more instance fields are part of the hash
code now in accordance with 'equals'.
The new test helper class LogicalPointcutStructure is able to recognise
chained '&&' and '||' pointcuts of the same logical nesting level,
un-nesting them from the actual pointcut structure and making them
comparable, disregarding their order. I.e., something like
((A && B) && C) && D
is actually recognised to logically be
A && B && C && D
and equivalent to e.g. either of
D && B && A && C
A && B && D && C
C && A && D && B
This helps to compare rewritten pointcuts, as long as their logical
structure has not been altered.
Relates to #24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
WildTypePattern: fix hashCode and toString methods
Especially 'hashCode' did not correspond to 'equals', disregarding
several fields, array dimension information being only one of them. This
led to parts of pointcuts being ignored, because they were regarded as
duplicates. Example:
execution(Foo* *(..)) && !execution(Foo*[] *(..))
Here, the negated pattern was falsely regarded as equal to the first
pattern, leading to an "A && !A" situation, i.e. no match at all.
Furthermore, 'toString' did not print array strings, i.e. instead of
"Foo*[][]" something like "Foo*" was printed. This false information was
also present in annotations generated by the weaver.
FuzzilyMatchingAspect was adjusted to actually match exactly once, as
expected, for the "Foo*" return types, i.e. exclusions for the array
return types have been added.
Relates to #24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Handle one- and multi-dimensional array return types correctly
Fixes https://github.com/eclipse/org.aspectj/issues/24, both the array
return type matching as such as well as matching dimensionality patterns
correctly. E.g., 'Foo*[]' is not the same as 'Foo*[][]'. This also works
correctly in combination with asterisks, even for primitive types, i.e.
'in*[][]' correctly matches a 2-dimensional array of 'int'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Simplify if-else in WildTypePattern.matchesExactlyByName
A simple boolean condition is enough.
Loosely relates to https://github.com/eclipse/org.aspectj/issues/24, but
actually it is just drive-by cosmetics.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The method falsely determined that a one-dimensional array was not an
array due to a one-off bug.
Relates to https://github.com/eclipse/org.aspectj/issues/24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
More test cases were added for
- multi-dimensional arrays,
- primitive type arrays.
Relates to https://github.com/eclipse/org.aspectj/issues/24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Refactor, comment and reactivate Ajc183Tests.testAnnoStyleDecp_442425
This test was always inactive and did not add any value other than
during development. No it runs, passes and documents the status quo of
- what was fixed (regression for AJC 1.8.2 core dump fixed in 1.8.3),
- the current limitations of @DeclareParents and @DeclareMixin
regarding generic interfaces.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
BcelTypeMunger.mungeMethodDelegate: only use 'synchronized' when necessary
Relates to #198. Now, we create a delegate method body which basically
looks as follows:
public void methodOne() {
if (this.ajc$instance$MyAspect$MyMixin == null) {
synchronized(this) {
if (this.ajc$instance$MyAspect$MyMixin == null) {
this.ajc$instance$MyAspect$MyMixin = MyAspect.aspectOf().createImplementation(this);
}
}
}
this.ajc$instance$MyAspect$MyMixin.methodOne();
}
The idea for the outer null check is from @aclement, see
https://github.com/eclipse/org.aspectj/pull/205#issuecomment-1371556080.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
No more compiler errors for implicitly static inner aspects of interfaces
Fixes #162. Contains regression test
Bugs1919Tests.testInterfaceInnerAspectImplicitlyStatic.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Improve BcelTypeMunger.mungeMethodDelegate to avoid race condition
Fixes #198, i.e. test DeclareMixinTests.testCaseEConcurrent from the
previous commit now passes.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This commit is a follow-up for 65f1ec72. The SOURCE retention case is
documented now and considered in a few more call sites. The
previously already similar code structures in
- DeclareAnnotation.ensureAnnotationDiscovered,
- DeclareAnnotation.getAnnotationType
have both been streamlined and still remain logically in sync.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
BCEL: use MAX_CP_ENTRIES from internal class, not from JRE
Instead of importing com.sun.org.apache.bcel.internal.Const, use
use org.aspectj.apache.bcel.Constants. The former class is from the
internal JRE module 'java.xml' which is not exposed by default.
Actually, no existing test failed because of it, but javadoc generation
for the AspectJ weaver.
Relates to #192.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix #366085 concerning declared annotations with source retention
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=366085.
See https://stackoverflow.com/q/74618269/1082681.
The issue described in the Bugzilla issue is about 'declare @type', but
similar issues also existed for 'declare @field', 'declare @method',
'declare @constructor'. This fix is rather superficial and leaves
things to be desired, because it is rather hacky and simply ignores
errors source retention annotation declarations during weaving. A better
fix would drop the corresponding declarations while parsing and also
issue compiler warnings in each case.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
OutputSpec.matchesThisVm better supports version ranges
vmVersionRanges might be a single version like "9", a list of versions
like "1.2,1.3,1.4,1.5", an equivalent range of "1.2-1.5", an open range
like "-1.8", "9-" (equivalent to "9+") or a more complex list of ranges
like "-1.6,9-11,13-14,17-" or "8,11,16+".
Empty ranges like in "", " ", "8,,14", ",5", "6-," will be ignored.
I.e., they will not yield a positive match.
Bogus ranges like "9-11-14" will be ignored, too.
Existing XML test specs using '<line text="..." vm="v,v2,...,vn"/>
have been adjusted to use version ranges rather than long lists of
consecutive versions. Furthermore, ranges with a trailing '+' like '14+'
were replaced by using the new canonical format '14-', even though the
parser still correctly recognises '14+'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
LangUtil: improve Java version major/minor parsing
- Ignore everything including and after '+' in versions like '19+36-2238'
- Add minor '.0' to Java versions like '19', '19+36-2238'
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
For now, only the "pattern matching for switch" tests from previews 1
and 2 were adjusted to work in preview 3, because guarded patterns were
replaced by 'when' clauses in 'switch' blocks. Therefore, existing test
classes did not compile anymore and had to be replaced by syntactically
upgraded versions with content merged from preview 1 and 2 classes.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Firstly, Batik is not needed for running AspectJ tests.
Secondly, the fixed Windows path separators led to GitHub CI/CD tests
failing under Java 18+ on GitHub. Replacing ';' by 'File.pathSeparator'
would have fixed the problem, but removing the paths altogether is the
cleaner solution.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Even though we just upgraded to 9.3 for Java 19, it does not hurt to
have ASM recognise the Java 20 class file major version.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In messages_aspectj.properties, set compiler.version to
"Eclipse Compiler 5fd28398cc (21Sep2022) - Java19".
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add docs/dist/LICENSE-AspectJ.html to all public artifacts
The license file will be included right in the main directory of both
binary and source artifacts for
- AspectJ Matcher,
- AspectJ Runtime,
- AspectJ Weaver,
- AspectJ Tools (Compiler),
- AspectJ Installer.
Fixes #185.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch