paulk-asert opened a new pull request, #2816:
URL: https://github.com/apache/groovy/pull/2816
…nter's target type
The indirect import check asked about a method pointer's own type. A
MethodPointerExpression fixes that to groovy.lang.Closure in its constructor,
so the check never concerned the class the pointer is taken on, and its second
argument was the whole expression text where assertStaticImportIsAllowed
expects a member name.
Both modes were wrong, in opposite directions. Measured with the check
enabled:
disallowedImports = [java.lang.ProcessBuilder]
new ProcessBuilder() blocked
ProcessBuilder.&new allowed
ProcessBuilder::new allowed
allowedImports = [java.util.ArrayList]
ArrayList.&size refused
The deny list missed the pointer entirely, since nothing names Closure in
one. The allow list refused every pointer, including pointers to a class it
allowed, because Closure is not in an allow list either. So the check both let
through what it was meant to stop and stopped what it was meant to allow.
Ask about the class the pointer is taken on, unwrapping arrays through the
same helper the method call branch uses, and pass the method name rather than
the expression text.
This changes behaviour in both directions, each toward what the flag
documents: a denied target is now refused, and a pointer to an allowed target
is now permitted where it was refused before.
An existing assertion covered java.util.LinkedList.&size under an allow
list, and passed only because Closure was absent from that list; it passes
after this change too, now for the reason it appears to be testing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
