aboutsummaryrefslogtreecommitdiffstats
path: root/run-all-junit-tests
diff options
context:
space:
mode:
authorAlexander Kriegisch <Alexander@Kriegisch.name>2023-01-17 19:23:26 +0100
committerAlexander Kriegisch <Alexander@Kriegisch.name>2024-04-12 15:32:39 +0200
commited0a8ea17b691489057b670f1b6859e025d6c7c8 (patch)
tree9e2026ff21ba0269bcbe830fcde5eda1ef41bfcd /run-all-junit-tests
parentcad9346701b4ef3884283886948b0c2504e00e17 (diff)
downloadaspectj-ed0a8ea17b691489057b670f1b6859e025d6c7c8.tar.gz
aspectj-ed0a8ea17b691489057b670f1b6859e025d6c7c8.zip
New Xlint warning 'arrayCannotBeVoid' when resolving 'void[]'
Because void arrays are illegal (and nonsensical), now there is a new Xlint warning whenever World.resolve resolves a new 'void[]'. Because in the World class we do not have any source context, no path + line number are logged. The user only sees something like: [warning] arrays cannot have a void type, but found 'void[]' in pointcut [Xlint:arrayCannotBeVoid] Then later, if due to the returned MissingResolvedTypeWithKnownSignature type a joinpoint does not match, there is an additional my/path/MyAspect.aj:42 [warning] advice defined in MyAspect has not been applied [Xlint:adviceDidNotMatch] log line, but not necessarily anywhere near the former one. On the one hand, this is better than nothing. OTOH, comparing the situation with no logging message other than Xlint:adviceDidNotMatch in case of something equally illegal like 'Foo<int>' (primitive generic type parameter), this is actually more than we have in several other situations and might even be regarded as superfluous. In case of multiple 'void[]' cases within a big number of aspects, the same aspect or even the same pointcut, the user would have no clue where exactly to search for it. He would just see multiple log messages without source context. One option would be to set 'arrayCannotBeVoid=ignore' in XlintDefault.properties, so the user would have to explicitly activate it. But IMO, this message should be visible by default. Another option would be to find out how to defer logging the messages until later similarly to BcelWeaver.warnOnUnmatchedAdvice and then to bulk-print them. But in order to achieve that, the information about the existence of any 'void[]' occurrences would have to be stored in a flag similar to BcelAdvice.hasMatchedAtLeastOnce, bloating BcelAdvice for that rare case. Alternatively, each advice pointcut could be heuristically scanned for the literal substring 'void[]', logging the Xlint message if it is found anywhere. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Diffstat (limited to 'run-all-junit-tests')
0 files changed, 0 insertions, 0 deletions