You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tensorflow.xml currently models per-instance method dispatch and field attachment by duplicating the entire method/putfield block at every allocation site. Examples:
Model allocations similarly repeat method-attachment blocks across multiple endpoints.
If a future migration moves set_shape recognition into tensorflow.xml (filed separately as wala/ML#NNN), it would either replicate the pattern or require a class-method <method> declaration that the WALA Python frontend dispatches via virtual lookup (works today, per empirical probe 2026-05-26).
Goal
Eliminate the duplication by declaring instance methods and instance fields ONCE on a base class, and propagating them to subclass allocations via WALA's class-hierarchy mechanism.
Inheritance not supported #107 — Inheritance not supported (more general). Must support class D(B): pass resolving methods on B.
Both are open. This issue is the natural consumer of those fixes.
Out of Scope
This issue is the cleanup counterpart of the underlying frontend fixes — not the frontend fixes themselves. #118 + #107 land in WALA / cast.python first; then this issue's dedup work follows.
Verification
Tests must still pass after dedup (mvn test from root). The audit recipe from #549 (strip one block, count failures) is a reasonable canary while migrating.
Motivation
tensorflow.xmlcurrently models per-instance method dispatch and field attachment by duplicating the entire method/putfield block at every allocation site. Examples:Datasetmethod blocks (18 endpoints —from_tensor_slices.do,shuffle.do,batch.do, etc.) each repeat the full set of<putfield>s attaching method-name → callable bindings. Audit in Audit dataset-method field-duplication intensorflow.xml— comment cites 1-CFA but engine uses 2-CFA #549 confirmed the duplication is structurally load-bearing: strippingshuffle.do's block caused 19 test failures.Modelallocations similarly repeat method-attachment blocks across multiple endpoints.set_shaperecognition intotensorflow.xml(filed separately as wala/ML#NNN), it would either replicate the pattern or require a class-method<method>declaration that the WALA Python frontend dispatches via virtual lookup (works today, per empirical probe 2026-05-26).Goal
Eliminate the duplication by declaring instance methods and instance fields ONCE on a base class, and propagating them to subclass allocations via WALA's class-hierarchy mechanism.
Pre-Conditions
com.ibm.wala.classLoader.IClass.getSuperclass()incorrectly returnsLobject#118 —IClass.getSuperclass()incorrectly returnsLobjectfortf.keras.Modelsubclasses. Must work correctly for class-hierarchy traversal to find inherited methods.class D(B): passresolving methods onB.Both are open. This issue is the natural consumer of those fixes.
Out of Scope
This issue is the cleanup counterpart of the underlying frontend fixes — not the frontend fixes themselves. #118 + #107 land in WALA /
cast.pythonfirst; then this issue's dedup work follows.Verification
Tests must still pass after dedup (
mvn testfrom root). The audit recipe from #549 (strip one block, count failures) is a reasonable canary while migrating.Related
tensorflow.xml— comment cites 1-CFA but engine uses 2-CFA #549 — audit confirming duplication is currently load-bearing (rationale comment updated in PR Prevent future inappropriate print statement usage with checkstyle-based build-time enforcement #334)tensorflow.xmlcom.ibm.wala.classLoader.IClass.getSuperclass()incorrectly returnsLobject#118 + Inheritance not supported #107 — class-hierarchy resolution (pre-conditions)