Re-baseline the legacy failure set after the Bifrost v0.10.5 jump

[DavidBakerEffendi]

Re-pinning Bifrost for the v0.3.1 legacy freeze (#155) is not a one-line change
in effect. 511adaa (v0.10.1) to 79ea68cf (v0.10.5) is 31 commits and 300
files, so the expected-failure set recorded in #155 is stale and should be
re-measured before it is used to judge a freeze run.

Why the current prediction cannot be trusted

#155 lists 10 expected failures, derived from the v0.10.1 run in
32177552346.
At least one upstream fix plausibly moves cases in that list.

4016e763 ("make summary spellings round-trip through symbol resolution")
states:

A Scala case class and its companion object split into two ambiguity
selectors that display identically, so the listed spelling
(CharsetRange.Atom) never resolved

Two of the ten predicted failures are exactly that shape:

• scala-parity-case-class-generated-construction-and-copy
• scala-parity-case-class-generated-component-access

Both failed with no_declaration — Bifrost returning nothing when navigating
from a generated member back to its declaration. A companion-object selector
that never resolved is a credible cause. This is a hypothesis, not a finding;
it needs the run to confirm.

The same commit also fixes a leading-dollar identifier being read as a nesting
join ($LogProvider), which is the JavaScript analogue of the PHP sigil
confusion, and file-anchor normalization. Both could move cases in ways the
v0.10.1 baseline does not predict.

What to do

Run the legacy corpus against the new revision before committing
multi-hour freeze time, and record the real outcome set. Cases may move in
either direction — a newly passing case is as much a baseline change as a newly
failing one, and improved is a distinct outcome the runner already reports.

Then update #155's expected set from measurement rather than from the July
comparison.

Related

• Publish the reviewed legacy core as v0.3.1 #155 — the freeze this feeds
• Reconcile the 24 July development page with the PHP audit #157 — a separate instance of a stale summary being read as current evidence

[DavidBakerEffendi]

Re-baselined. Ran the 110-case balanced core against v0.10.5 (d775e3b4)
natively and diffed it against the v0.10.1 report from
32177552346.

Totals

	v0.10.1	v0.10.5
passed	97	98
improved	0	1
failed	12	11
expected failures	1	0
required destinations found	100/110	102/110
TP / FP / FN	283 / 7 / 19	289 / 8 / 13

Only two cases moved

• php-property-access — failed → passed. Both halves confirmed:
  Bifrost now reports the sigil-inclusive declaration range (12:19-24, was
  12:20-24), and the symbol Example.Repository.last resolves against the
  authored $last through the matcher added in Fix legacy freeze case-count gates and PHP sigil matching #152.
• cpp-parity-function-like-macro-expanded-call — expected_failure →
  improved. Its usage→declaration lookup went from no_definition to ok
  at the expected 45:20. Bifrost now navigates the macro-expanded call, so
  the annotation asserting it cannot is stale. Filed as Retire the expected failure on cpp-parity-function-like-macro-expanded-call #164.

Everything else is byte-identical across the two runs.

The Scala hypothesis did not hold

I suggested the companion-object ambiguity fix in 4016e763 might move
scala-parity-case-class-generated-construction-and-copy and
-component-access. It did not. Both are unchanged — same selectors, same
missing/unexpected sets, same u2d statuses (ok + position_unverified,
and no_declaration respectively). Recording that so nobody re-derives it.

The other PHP case still fails, for a different reason

php-parity-static-property-access still fails, but the failure moved.
Resolution now succeeds (selector=App.Service.EmailNotifier.sent,
raw=['found'], declaration lookup ok) — what remains is on the usage
side: Bifrost returns sigil-exclusive ranges for static-property usages.
Filed as #165.

Method note

The first attempt reported 108/110 failed with 104 symbol_resolution_failed.
That was my staging, not Bifrost: stage-legacy-promotion-corpus.py run
against the working tree copies target/, tests/, and docs/node_modules
into the corpus, and the analyzer indexes them. The freeze runs
stage-release-bundle.sh first, which excludes them. Fixture content is
identical between the two stagings — only the surrounding tree differs. Worth
knowing before anyone reproduces this.

Expected set for #155

Eleven failures, all with a recorded cause. Anything outside this list in the
freeze run is new and should be investigated rather than accepted:

cpp-parity-using-alias-constructor · csharp-parity-namespace-alias-constructor ·
go-interface-receiver-method-call · js-commonjs-barrel-member-call ·
js-parity-computed-string-literal-method-call · php-parity-static-property-access ·
python-barrel-inherited-member-call · python-module-import ·
scala-parity-case-class-generated-component-access ·
scala-parity-case-class-generated-construction-and-copy ·
scala-parity-trait-method-implementation

Plus one improved (the C++ macro case) until #164 lands.

Caveat: this was a native host run, which reports label themselves
host_specific. The freeze produces Bifrost's report through the reference
container. I would expect agreement, but the container run is the authority.

[DavidBakerEffendi]

Re-measured under v0.10.6

Controlled comparison: same machine, same day, same execution mode, only the
Bifrost revision differs. Filtered to the 110 promoted balanced-core cases via
the promotion manifest — all 110 present in both runs.

	v0.10.5	v0.10.6
passed	98	106
improved	1	1
failed	11	3

Method note. These were run against the repository tree rather than a
staged corpus, because staged runs on this machine currently report the
analyzer unavailable for every language (local fault: v0.10.5 fails identically
there, and a corpus that scored 98/110 four days ago now scores 0 while
unchanged on disk).

That substitution is validated rather than assumed: the v0.10.5 repo-tree run
reproduces 98 / 11 / 1 exactly, matching the v0.10.5 staged run from
32177552346.
Repo-tree and staged execution agree for the version where both are available,
so the v0.10.6 figure is a like-for-like comparison.

Twelve cases moved

Ten fixed, including the one this whole thread was chasing:

cpp-parity-using-alias-constructor · csharp-parity-namespace-alias-constructor ·
go-interface-receiver-method-call · js-commonjs-barrel-member-call ·
js-parity-computed-string-literal-method-call · php-parity-static-property-access ·
python-barrel-inherited-member-call · python-module-import ·
scala-parity-case-class-generated-component-access ·
scala-parity-trait-method-implementation

Note this retires the open question from the original issue: go-interface-receiver-method-call
and scala-parity-case-class-generated-component-access were the two I could not
confirm were pre-existing rather than regressions. Both now pass.

Two regressed — filed as #170:

• rust-struct-construction
• rust-parity-module-declaration-definition

Revised expected set for #155

3 failures + 1 improved:

• rust-struct-construction (regression, Two Rust cases regressed between Bifrost v0.10.5 and v0.10.6 #170)
• rust-parity-module-declaration-definition (regression, Two Rust cases regressed between Bifrost v0.10.5 and v0.10.6 #170)
• scala-parity-case-class-generated-construction-and-copy (pre-existing)
• cpp-parity-function-like-macro-expanded-call — improved, stale expectation (Retire the expected failure on cpp-parity-function-like-macro-expanded-call #164)

Anything outside that set in the freeze run is new. Superseding the earlier
10 + 1 prediction in this issue, which was taken under v0.10.5.