`MemberResolver` misses members inherited via self-referential interface (`ResolvedRecursiveType` as implemented interface)
已經有一個關聯 PR 被合併了。
- #135 來自 @cowtowncoder —— 已合併
評估
研究方向
Start with MemberResolver and how it walks implemented interfaces, then look at ResolvedRecursiveType.getImplementedInterfaces(), which returns an empty list. Compare with the super-class handling in ResolvedObjectType.getParentClass() that #128 added. Done when the self-referential outerInMid from the reproduction yields the same member methods (get(), top()) as stand-alone OuterI.
由索引模型根據 Issue 內容生成。
描述
When an implemented interface of a type is a self-reference (ResolvedRecursiveType), it is returned as-is by getImplementedInterfaces(); and since ResolvedRecursiveType.getImplementedInterfaces() returns an empty list (to avoid infinite loops), MemberResolver silently drops all members inherited through that interface.
Reproduction
public interface Top { void top(); }
public interface BaseI<X> extends Top { X get(); }
public interface MidI<T> extends BaseI<OuterI> { }
public interface OuterI extends MidI<String> { }
TypeResolver r = new TypeResolver();
MemberResolver mr = new MemberResolver(r);
// `OuterI` as type parameter of `BaseI<OuterI>`, within `MidI<String>`:
ResolvedType outerInMid = r.resolve(MidI.class, String.class)
.getImplementedInterfaces().get(0).getTypeParameters().get(0);
mr.resolve(outerInMid, null, null).getMemberMethods().length; // 0
mr.resolve(r.resolve(OuterI.class), null, null).getMemberMethods().length; // 2 (`get()`, `top()`)
Here outerInMid implements MidI<String> via a self-reference (since MidI<String> was still being resolved), so BaseI and Top (and their methods) are not reachable.
(note: on 1.7 / current main, even stand-alone OuterI resolves to 0 member methods)
Expected
Same members as for stand-alone OuterI.
Notes
#128 handled the equivalent case for super classes: ResolvedObjectType.getParentClass() maps a self-referential super class to the type it represents (ResolvedRecursiveType.getActualType(), new in 1.8). Super interfaces would need similar handling: either in getImplementedInterfaces() of ResolvedObjectType / ResolvedInterfaceType, or in MemberResolver (HierarchicType construction) when traversing interfaces. Changing what getImplementedInterfaces() returns would be a (minor) behavioral change, so MemberResolver-side handling may be preferable.
- 主要語言
- Java
- 星號
- 266
- 分支
- 53
- 平均合併
- 18 小時 46 分鐘
- 30 天內合併 PR
- 8
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
FasterXML/java-classmate 的其他 Issue
-
難度 5/5 一週以上 新手友好度 25/100
FasterXML/java-classmate#111 · 10 則留言 ·
-
難度 5/5 一週以上 新手友好度 20/100
FasterXML/java-classmate#81 · 1 則留言 ·
-
Make `GenericType<T>` not implement `java.lang.reflect.Type`可能已有人在做 @cowtowncoder 於 314 天前認領。 未關閉
難度 4/5 3-5 天 新手友好度 35/100
FasterXML/java-classmate#76 · 6 則留言 · 1 個 reaction ·
-
難度 5/5 一週以上 新手友好度 20/100
FasterXML/java-classmate#72 · 3 則留言 ·
-
難度 4/5 3-5 天 新手友好度 35/100
FasterXML/java-classmate#69 · 22 則留言 ·
查看 FasterXML/java-classmate 的全部 Issue
相似的 Issue
-
documentation
難度 2/5 1-3 小時 新手友好度 62/100
devops-thiago/ThrillhouseBot#1132 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 66/100
維護者通常 1 天內回覆
-
approved bug
難度 2/5 1-3 小時 新手友好度 70/100
checkstyle/checkstyle#21981 · 1 則留言 ·
維護者通常 1 天內回覆
-
Build: the CUDA backend fails without cuDNN instead of skipping the cuDNN shim (as the cuDF shim does)可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 68/100
beehive-lab/TornadoVM#1248 ·
維護者通常 1 天內回覆
-
good first issue help wanted ready-for-human
難度 2/5 半天 新手友好度 64/100
維護者通常 1 天內回覆