GROOVY-11929: drop abstract methods from methodsForSuper if no MOP match#2472
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2472 +/- ##
=================================================
+ Coverage 0 67.1426% +67.1426%
- Complexity 0 30913 +30913
=================================================
Files 0 1436 +1436
Lines 0 119842 +119842
Branches 0 21239 +21239
=================================================
+ Hits 0 80465 +80465
- Misses 0 32675 +32675
- Partials 0 6702 +6702
🚀 New features to boost your workflow:
|
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes GROOVY-11929 by ensuring methodsForSuper does not retain abstract methods that are not replaced by MOP “super$N$…” methods, preventing runtime failures when resolving super calls in certain generic/interface override scenarios.
Changes:
- Add regression test covering a generic DAO + interface override scenario where an abstract method could remain in
methodsForSuper. - Extend
MetaClassImpl#replaceWithMOPCallsculling logic to remove abstract methods frommethodsForSuperwhen no MOP match exists. - Minor refactor/clarification in
MetaMethodIndex#isOverriddencondition structure (no behavioral change).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/test/groovy/bugs/Groovy11929.groovy | New regression test reproducing the problematic super.save(...) resolution scenario. |
| src/main/java/org/codehaus/groovy/runtime/metaclass/MetaMethodIndex.java | Small readability-only tweak to override decision logic. |
| src/main/java/groovy/lang/MetaClassImpl.java | Drops non-replaced abstract methods from methodsForSuper during MOP replacement to avoid selecting non-invokable methods. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
blackdrag
approved these changes
Apr 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Java classes as well as Groovy classes with special super circumstances (see GROOVY-11929) have abstract methods in the
methodsForSuperindex not replaced by MOP methods. These can be discarded, since they are not callable. This is an extension of the culling of bridge and some other methods from this index.In the test example, the index for
EntityDaoImplcontains an entrysave: ["save(T) from AbstractDao", "save(Entity) from EntityDao"]beforeMetaClassImpl#replaceWithMOPCallsruns. After it runs the index containssave: ["super$2$save(Object) from EntityDaoImpl", "save(Entity) from EntityDao"]. "save(Entity)" is abstract and is not replaced by a MOP method (due to the parameter matching). So discard it to prevent the runtime error.