mirror of
https://github.com/abhigyanpatwari/GitNexus.git
synced 2026-10-29 06:32:28 +00:00
8aab141f8e
`ResolutionOutcome` recorded a dropped site's file, name and range but not
what the site actually WAS. Case 0's gate tests the receiver's punctuation
(`receiverName.includes('.') || receiverName.includes('(')`), not the site's
kind, so a compound-receiver property write is recorded in the same bucket as
a dropped method call:
svc!.getUser().save(); // a lost CALLS edge
svc!.getUser().name = 'x'; // a lost ACCESSES edge
Both are real drops, but they are not the same defect and they are not fixed
by the same work. Anything measuring resolver gaps has to separate them, and
until now nothing could: `PipelineResult` exposes no `parsedFiles`, so a
consumer has no join key back to the reference site, and the only remaining
option was to regex-classify the source line — the same textual-shape dispatch
that receiver typing is trying to get away from, applied to the number you
would use to judge the work.
So the pass records `siteKind` at the one place it emits `receiver-unresolved`.
Diagnostic only. `summarizeUnresolvedReceivers` reads `kind`, `reason` and
`name`, so `RepoMeta.unresolvedReceiverMembers` — and therefore the `epistemic`
signal built on it in #2744 — is byte-for-byte unchanged. The field is optional
on the union member, so the other twenty-odd `recordResolutionOutcome` sites,
which emit other reasons, are untouched.
Both test shapes are empirically confirmed drops rather than assumed ones: `!`
produces a reference site that reaches Case 0. `?.` and explicit type arguments
notably do NOT — they emit no edge and record no drop, so they are invisible to
this recorder entirely. That is a property of the capture layer, not of this
field, and it is worth knowing before anyone gates a decision on a drop count.
|
||
|---|---|---|
| .. | ||
| fixtures | ||
| helpers | ||
| integration | ||
| unit | ||
| utils | ||