Further improve indentation of compilation results on the console
In CompilationResult.toString, no longer indent like this:
[warning 1] warning at
after() : execution(FooBar Blah.*()) {
^^^^^^
xxx FooBar [Xlint:invalidAbsoluteTypeName]
Instead, always just indent by 2 spaces, saving screen real estate:
[warning 1] warning at
after() : execution(FooBar Blah.*()) {
^^^^^^
xxx FooBar [Xlint:invalidAbsoluteTypeName]
Also further streamline/simplify the code a bit.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix indentation of compilation results on the console
Whenever warnings or errors were printed via CompilationResult.toString,
indirectly also using MessageUtil.renderMessage(IMessage, boolean),
messages containing context info such as code snippets with carets
marking erroneous tokens - see also the previous commit - prefixes like
"[warning 1] warning at " were printed right in front of the code
snippets. I.e., the carets marking erroneous tokens in the second line
were not indented like the first line with the code snippet, leading to
(simplified) output like:
[warning 1] warning at after() : execution(FooBar Blah.*()) {
^^^^^^
xxx FooBar [Xlint:invalidAbsoluteTypeName]
This was fixed to now correctly indent lines 2 to n according to line 1,
yielding the correct output:
[warning 1] warning at
after() : execution(FooBar Blah.*()) {
^^^^^^
xxx FooBar [Xlint:invalidAbsoluteTypeName]
Especially with longer, more complex context lines, this helps to
identify the erroneous section. BTW, for one-line messages, everything
of course looks like before.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Bugfix: caret error marks in compiler output too short
This very old bug in EclipseAdapterUtils calculated the '^' caret error
marks incorrectly. The marks were too short like this:
void m() { return vax[3]; }
^^^^^^^^^^^
Where the correct result would look like this:
void m() { return vax[3]; }
^^^^^^^^^^^^^^
This was due to the rather complicated way in which first surrounding
context code - here the leading 'void m() { ' and trailing ' }' - was
first added and then possible leading white space was cut off again from
the left. It is difficult to explain, the code is a nightmare, trying to
work with char arrays, counting indexes, repeatedly using
System.arraycopy and using lots of counters and offsets. I would have
liked to simplify the code, converting char[] buffers to Strings, but
decided to keep the basic structure for now, not sure what kind of
memory or performance considerations led to this design.
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>
In messages_aspectj.properties, set compiler.version to
"Eclipse Compiler 5fd28398cc (21Sep2022) - Java19".
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Make IStateListener.aboutToCompareClasspaths use typed lists
Before, the signature was:
void aboutToCompareClasspaths(
List oldClasspath, List newClasspath);
Now it is:
void aboutToCompareClasspaths(
List<String> oldClasspath, List<String> newClasspath);
AJDT will also use the typed version after generics refactoring.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
AjcTestCase: be less verbose when appending to buffer repeatedly
Also put 'else (if)' and 'finally' on new lines rather than after the
preceding closing curly braces. This helps IDEs when using code folding
(show/hide content of code blocks enclosed in curly braces).
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Make sure to always print commands when running Java test classes
In some cases, the 'java ...' command was not printed, which is
especially unhelpful when tests fail.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Use upstream method to generate '--add-reads', '--add-exports' info
and copy it into our FileSystem instance. In order to be able to access
JDT Core's FileSystem.moduleUpdates field, we had to make it public
there first.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add test case + experimental fix for AJC option '--add-exports'
I am expecting the test case to pass, but other tests to fail. This
temporary commit is meant to create feedback from GitHub CI test runs.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
At present, no tests are failing without those resources, but for good
measure, I added them anyway, because then the same path could in the
future also be used for stand-alone compilation tests which are not
triggered in-process via AJDT interface but, not unlike "full LTW"
test execution mode, in a separate JVM.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Make sure that program arguments are passed through in full LTW mode
This fixes e.g. LTWTests.testDeclareAbstractAspect, which passes on
names of ITD methods to the test program, which in turn executes those
methods via reflection.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In 'useFullLTW' mode, aspectjweaver.jar is a Java agent. Therefore, what
is contained in there does not need to be on the classpath.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
It was referring to a no longer existent weaver under
aj-build/dist/tools/lib/aspectjweaver.jar, which now has been replaced
by the new file lib/aspectj/lib/aspectjweaver.jar.
Several tests were broken, not finding the agent. But because those
tests make no assertions, nobody ever noticed. Only when I had to change
some LTW tests from in-process to full LTW mode (see next commit) due to
them now obviously calling some code paths which need '--add-opens', I
even noticed the problem.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix annotation style support for if(true) and if(false)
The documentation specifies annotation style pointcuts
can use if(false) or if(true) and not require a boolean
return value and body for the @Pointcut annotated
method but it doesn't work without this change to validation
that recognizes the situation.
Fixes #115
Methods Integer.parseInt/Boolean.parseBoolean should be preferred over Integer.valueOf/Boolean.valueOf/ if final result is primitive.
They are generally faster and generate less garbage.
Alexander Kriegisch
Andrey Turbanov
Andy Clement