[
https://issues.apache.org/jira/browse/GROOVY-12105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091737#comment-18091737
]
ASF GitHub Bot commented on GROOVY-12105:
-----------------------------------------
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.
> Unqualified super.m(...) from a static trait method throws
> MissingMethodException — should be a compile error or walk the trait chain
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12105
> URL: https://issues.apache.org/jira/browse/GROOVY-12105
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> Inside a trait STATIC method, an unqualified `super.m(...)` call does
> not walk the trait chain documented for the instance-method case
> (GEP-22 § "this, super, and stackable traits" item 2). The call
> compiles successfully but throws MissingMethodException at runtime.
> Minimal reproducer:
> {code:groovy}
> trait Base { static String m() { 'Base' } }
> trait V extends Base {
> static String m() { 'V' }
> static callSuper() { super.m() } // unqualified, from static
> }
> class Impl implements V { }
> Impl.callSuper()
> {code}
> Expected: either resolve to Base.m (matching the spec's "walks the
> trait chain" semantic for the instance case) or reject at compile
> time as an unsupported construct.
> Actual (consistent across 4.0.32, 5.0.6, 6.0.0-alpha-1):
> java.lang.MissingMethodException: No signature of method:
> static Base.m() is applicable for argument types: () values: []
> Contrast: the instance-method version of the same shape
> (without `static`) works as the spec documents — returns 'Base'.
> Plain Java/Groovy `super.m()` for class statics works normally
> (returns the parent class's m()), so the limitation is specific to
> trait static methods.
> *Recommended fix*: either implement the trait-chain walk for statics
> (symmetric with the instance-method case), or reject at compile time
> with a clear error pointing to `T.super.m(...)` as the explicit form.
> The latter is simpler and matches the recommendation in the GEP-22 v5
> draft (§ "this, super, and stackable traits" item 4, already drafted
> as part of the GEP-22 PR companion to this ticket).
> *Test coverage*: row 15 in
> src/test/groovy/org/codehaus/groovy/transform/traitx/TraitStaticDispatchMatrix.groovy
> is currently @NotYetImplemented asserting the compile-error
> end-state; will flip red when this ticket is resolved.
> *Related*: GROOVY-11985, GROOVY-12093, JIRA #1 (T.this in trait body).
> Both surfaced during empirical sweep for Grails alternatives.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
