Repository navigation
Conversation
|
I ran this against Wrong edges removed.
Problems. Each has a minimal repro in
A CHANGELOG entry is also missing. Composition with #1942. It merges cleanly with #1942, and the two are complementary: #1942 types field-name receivers ( |
|
Thanks for the SystemUI differential. I am auditing all 37 newly linked call sites individually against the public AAOS/AOSP sources. Could you share the 37-row edge diff (source file/line and expression, I will report a verdict for each call site, including the seven gains outside the approximately 30 wrong ones you identified. |
|
I applied your findings in I reindexed the same public source revisions with
The public AOSP source tree is different from your decompiled ~3.4k-Java-file corpus. I cannot label your exact 37 gains without the matching artifact or edge diff; my earlier request for the diff/revision still stands. The full local suite passed (4,537 tests; 192 skipped), the affected resolver suite passed after the final code edit (218 tests), and |
|
Rechecked Fixed. The Overall: 171 call sites lost, 21 gained. The losses are the same wrong-edge classes as before: 90 Still wrong: 12 of the 21 gains. Every // com/android/systemui/Interpolators.java
import android.view.animation.Interpolator;
import android.view.animation.PathInterpolator; // framework class
public class Interpolators {
public static final Interpolator ALPHA_OUT = new PathInterpolator(0.0f, 0.0f, 0.8f, 1.0f);
}
// com/android/systemui/qs/PathInterpolatorBuilder.java
public class PathInterpolatorBuilder {
private static class PathInterpolator extends BaseInterpolator {
public float getInterpolation(float t) { ... }
}
}
// caller
float a = Interpolators.ALPHA_OUT.getInterpolation(t); // fe691b6 → PathInterpolatorBuilder::PathInterpolator::getInterpolationThe The 21 gained call sites. Source file:line is in the decompiled tree; the target is the qualified name:
The losses I spot-checked (30+) are all wrong edges on |
|
Thanks for the 21-row follow-up. I reproduced the The resolver now uses the declaring Java file's explicit import or qualified On Node 24.21.0, the resolver suite passed (218/218) and I cannot verify the exact 12/21 counts or every row's verdict without that decompiled source set and revision. The earlier request for the original 37-row diff and source boundaries still stands. The corresponding change for the already-merged fork version is separate in fork PR #5; its CI is pending and it has not been merged. |
|
Re-checked Fixed:
On the decompiled SystemUI corpus, the new head has 171 lost / 9 gained vs Blocker: interface constants aren't extracted by the native kernel. The change adds So the interface constant never becomes a node. The PR's own assertion fails with the kernel: interface Consts { Helper HELPER = new Helper(); } // p/Parent.java
class Helper { void go() {} }
class Calls { void f() { Consts.HELPER.go(); } } // main: Helper::go, this PR (kernel): no edgeThe fix is to mirror Minor: the wildcard fallback accepts a type from any package. When // com/app/W.java
package com.app;
import android.view.animation.*;
public class W { public static final Interpolator DECEL = new DecelerateInterpolator(); }
// com/third/DecelerateInterpolator.java (public, never imported by W)
package com.third; public class DecelerateInterpolator { public float getInterpolation(float t) { return t; } }
// W.DECEL.getInterpolation(t) → com.third::DecelerateInterpolator::getInterpolation (wrong)Accepting only types from the declaring file's package or from one of its Composition with our open work:
|
|
Thanks for the native-kernel reproduction. I confirmed the missing The kernel now extracts Java interface constants as static constants, with an interface constant in the Java kernel parity fixture. Static-field initializer matching now accepts an unqualified type only from the declaring package or an explicit wildcard-imported package; it no longer takes a unique class from an unrelated package. I also corrected dotted Java package matching, which a separate-file interface-constant probe exposed. With the native kernel built on Node 24.21.0, the resolver and kernel parity suites passed (239/239); The same commit is in separate fork PR #5; its new CI is running, and fork |
|
Re-checked Fixed:
New regression in // p/Outer.java
package p;
public class Outer {
public static class Inner {
public static final Inner A = new Inner();
public int getId() { return 0; }
}
}
// q/Caller.java
package q;
import p.Outer;
public class Caller { int f() { return Outer.Inner.A.getId(); } }
// main and b6ef5fb: p::Outer::Inner::getId 9d43926: no edgeMy guess is that the new "declaring package or explicit wildcard" check compares the unqualified On the decompiled SystemUI corpus this loses 6 edges that
Otherwise the corpus result is 179 lost / 11 gained vs |
|
Thanks for the nested-class repro. I reproduced With the native kernel on Node 24.21.0, the resolver and kernel parity suites pass (239/239), and Our public AOSP SystemUI source set at |
|
Fork integration status: mixxer/codegraph-aosp#5 is merged at This CI result does not reproduce the decompiled vendor SystemUI corpus. My earlier request for its exact edge diff, source revision, and indexed boundaries remains open; the public AOSP comparison has a different source set. |
c62caca to
3058165
Compare
This branch has not been deployed
2 participants
Summary
Prevent dotted Java static-field receivers from falling back to unrelated class methods. Preserve valid class receivers and Java access to indexed Kotlin object or companion singletons, including decompiled-style singleton fields. Keep Java extraction aligned between native and portable backends.
Public AOSP SystemUI and Play Framework source checks are separate from the maintainer’s decompiled vendor corpus. The vendor corpus’s reported 37 gained call sites still require its exact edge diff and source/index boundaries to classify.
Validation
6560052a6f856855d3f71eee838fd66ccfa4285d; tested head30581659913438165d6dbfa34019cb4a2dc0758b.