Copilot commented on code in PR #2629:
URL: https://github.com/apache/groovy/pull/2629#discussion_r3478754388
##########
src/main/java/org/codehaus/groovy/transform/trait/TraitReceiverTransformer.java:
##########
@@ -119,6 +120,23 @@ public Expression transform(final Expression exp) {
return transformBinaryExpression((BinaryExpression) exp);
} else if (exp instanceof MethodCallExpression mce) {
String obj = mce.getObjectExpression().getText();
+ // GROOVY-12105: in a static trait method, the parser/resolver
+ // rewrites `super.m(...)` to a static call on the trait's
+ // declared superclass (typically Object) before we see it. Reject
+ // that pattern at compile time, pointing at `T.super.m(...)` as
+ // the supported explicit form. The heuristic is narrow — it only
+ // fires when (a) we are in a static trait-method body (weaved is
+ // typed Class), (b) the receiver is a ClassExpression and (c) the
+ // expression type matches the trait's declared superclass.
+ if (ClassHelper.isClassType(weaved.getOriginType())
+ && mce.getObjectExpression() instanceof ClassExpression ce
+ && traitClass.getSuperClass() != null
+ && ce.getType().equals(traitClass.getSuperClass())) {
+ unit.addError(new SyntaxException(
+ "'super' is not allowed in a static trait method; use
'" + traitClass.getNameWithoutPackage() + ".super." + mce.getMethodAsString() +
"(...)' for explicit trait-anchored dispatch",
+ mce.getLineNumber(), mce.getColumnNumber()));
+ return mce;
+ }
Review Comment:
The GROOVY-12105 heuristic will currently fire for any method call on the
trait’s declared superclass inside a static trait method (e.g.
`Object.getName()` when the trait superclass is `Object`), because it matches
purely on `ClassExpression` type equality. That risks false-positive compile
errors for legitimate class-literal calls. Consider additionally verifying that
the receiver token in source was actually the `super` keyword (the rewrite
should preserve the original source position).
##########
src/test/groovy/org/codehaus/groovy/transform/traitx/Groovy12105.groovy:
##########
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.codehaus.groovy.transform.traitx
+
+import org.codehaus.groovy.control.MultipleCompilationErrorsException
+import org.junit.Test
+
+import static groovy.test.GroovyAssert.assertScript
+import static groovy.test.GroovyAssert.shouldFail
+
+/**
+ * Unqualified {@code super.m(...)} from a static trait method is rejected
+ * at compile time (GROOVY-12105). Without the reject, the call previously
+ * compiled successfully and threw {@code MissingMethodException} at
+ * runtime — the trait helper has no chain-walking for statics, and Java's
+ * JLS rule "Cannot use super in a static context" already disallows the
+ * pattern for plain classes.
Review Comment:
This class-level Javadoc cites the Java/JLS rule that `super` is disallowed
in a static context for plain classes, but Groovy does support `super.m()` in a
static method of a plain class (and this test class itself asserts that
behaviour). Tweaking the wording would avoid confusion about what’s being
enforced here (trait-only) vs. what Groovy permits for classes.
--
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]
