A whole class of formats is outside the model: identity-from-filename plus search-path resolution has no expressible edge #229

New issue

Open

opened 2026-09-08 15:59:18 +02:00 by buildagent · 0 comments

buildagent commented

2026-09-08 15:59:18 +02:00

Member

Measured on their corpus: 2,539 GridDef + 1,603 SearchDefinitionID occurrences across 3,942 tracked XAML files; all 389 distinct literals resolve to a tracked stem. It is the single highest-value cross-file relation in that format family, and none of it is reachable today.

The four reasons, in ascending order of how fundamental they are

1. Every bridge scope is directory-local. crates/indexer/src/bridges.rs:304-307:

"paired_file"    => "{c}.dir = {r}.dir AND {c}.pair_key = {r}.pair_key"
"same_directory" => "{c}.dir = {r}.dir"

same_file is narrower still. All three carry dir = dir, and the comment at :302 already says the consequence: "stem match across directories is same_directory plus a coincidence." Their edge is Views/Foo.xaml → LookupGrids/lg_incoterm.lgd — different directory, different stem, resolved at runtime by a four-root search path keyed on the stem alone. BRIDGE_SCOPES has no member for that.

2. The source ref lives in someone else's file. bridge.rs:30-34 — source_language is always <this package>/<local>, "not because a check refuses it, but because there is no way to build the value." The ref is in the .xaml, so only de.h-dv.xaml could ever declare this bridge, whatever another package's manifest says.

3. de.h-dv.xaml cannot be a destination anyway. It declares resolver = ["bridge_source"] and not bridge_destination, and index.rs:7933 enforces the destination grant as condition 3 on the candidate. So even the genuinely paired_file mirror edge (.shd → its sibling SearchDefs/<stem>.xaml, same directory, same stem) is blocked — on the XAML package's side, not the reporter's.

4. AND THERE IS NOTHING TO BIND TO. This is the one that makes the first three academic.

A bridge matches a source ref NAME to a destination symbol NAME. The destination symbol would have to be named lg_incoterm inside lg_incoterm.lgd. That string appears nowhere in that file. Their reader computes DefinitionId = Path.GetFileNameWithoutExtension(targetFile) before a byte is read; no element contributes to it. Same for .dataset, where dsFibuErrorLog is the identity and is not in the bytes.

So even granting 1, 2 and 3, the bridge would have no candidate.

Why this reframes the missing-path gap

extract(src_ptr, src_len, tree_ptr, tree_len) gives the guest no path. That has been treated — including by me, one message earlier in the same conversation — as a limitation on symbol coverage: a package cannot emit a nice-to-have module symbol named after its file.

It is not that. It is what makes the highest-value cross-file relation in 1,323 files unresolvable in principle. An entire class of formats works this way: identity from the filename, resolution by search path rather than by relative import. Definition files, resource dictionaries, config sets, typed-dataset descriptors. None of them can currently be linked to anything.

The cheap fix, and why it does not disturb the fact protocol

The reporter's proposal, and it is better than the obvious one. Not the full path — either the file STEM as a fourth input to extract, or an optional TAG_FILE_SYMBOL the guest may emit and the HOST validates against the real basename.

The second keeps the host owning the string, the way REL_QUALIFIERS already works. And critically, it does not touch the byte-equality rule, because symbols are already exempt from it. crates/abi/src/record.rs:920-927, verbatim:

THE NAME MUST BE THE BYTES IT POINTS AT. Refs are checkable this way and symbols are not: a ref's span is always the name node's own, while a symbol's decl covers the whole declaration and its name may be normalised (an impl Foo<T> symbol is named Foo).

So nothing in the fact protocol has to move. The missing thing is an INPUT, not an output. That is what makes this cheap enough to be worth doing.

The second ask, recorded with its own counter-argument

A non-proximity bridge scope — project_wide or by_stem — matching a destination anywhere in the project rather than in the same directory.

The reporter raised it and argued against it in the same breath, which is why it is worth recording rather than dismissing: dir = dir is what keeps the join bounded, and an unscoped name match across a 10k-file repository is a cross-product with obvious phantom risk — almost certainly why same_directory was chosen. Their position: "if the answer is 'no, and here is the cardinality that says why', that is a good answer I would record rather than re-litigate."

That is the right way to close it if it closes. But it should close with a measured cardinality, not with silence, because the class of formats it excludes is real and now has a number attached: four extensions, 1,323 files, in one repository.

What a fix must prove

A package can emit a symbol named from its own file, and the host — not the guest — decides that name. A guest asserting a name the host did not derive must be refused.
A fixture where the identity string is absent from the file's bytes, which is the whole case. A fixture whose stem happens to appear in the content proves nothing.
The byte-equality rule for REFS is untouched; mutate it and the existing span/name tests must still go RED.
If by_stem is implemented rather than declined: the cardinality of the join measured on a 10k-file repository, and a phantom count, before it is enabled by default.

Provenance

Filed from an external package author's analysis of bridges.rs, bridge.rs, index.rs and record.rs. I verified reason 4's load-bearing claim (record.rs:920-927) directly; the other three cite lines whose content matches. Their own package ships with no bridges and is unaffected either way — as they put it, "I would rather you heard this from a package author who went and read the SQL than from a bug report six months from now."

Reported by an external package author who went and read the SQL rather than filing a wish. They answered their own question in the process and the answer is worth more than the question was: the edge they wanted is **structurally inexpressible for four independent reasons**, and only the last one is really about bridges. Measured on their corpus: 2,539 `GridDef` + 1,603 `SearchDefinitionID` occurrences across 3,942 tracked XAML files; **all 389 distinct literals resolve to a tracked stem**. It is the single highest-value cross-file relation in that format family, and none of it is reachable today. ## The four reasons, in ascending order of how fundamental they are **1. Every bridge scope is directory-local.** `crates/indexer/src/bridges.rs:304-307`: ``` "paired_file" => "{c}.dir = {r}.dir AND {c}.pair_key = {r}.pair_key" "same_directory" => "{c}.dir = {r}.dir" ``` `same_file` is narrower still. All three carry `dir = dir`, and the comment at `:302` already says the consequence: *"stem match across directories is `same_directory` plus a coincidence."* Their edge is `Views/Foo.xaml` → `LookupGrids/lg_incoterm.lgd` — different directory, different stem, resolved at runtime by a four-root search path keyed on the stem alone. `BRIDGE_SCOPES` has no member for that. **2. The source ref lives in someone else's file.** `bridge.rs:30-34` — `source_language` is always `<this package>/<local>`, *"not because a check refuses it, but because there is no way to build the value."* The ref is in the `.xaml`, so only `de.h-dv.xaml` could ever declare this bridge, whatever another package's manifest says. **3. `de.h-dv.xaml` cannot be a destination anyway.** It declares `resolver = ["bridge_source"]` and not `bridge_destination`, and `index.rs:7933` enforces the destination grant as condition 3 on the candidate. So even the genuinely `paired_file` mirror edge (`.shd` → its sibling `SearchDefs/<stem>.xaml`, same directory, same stem) is blocked — on the XAML package's side, not the reporter's. **4. AND THERE IS NOTHING TO BIND TO.** This is the one that makes the first three academic. A bridge matches a source ref NAME to a destination symbol NAME. The destination symbol would have to be named `lg_incoterm` inside `lg_incoterm.lgd`. **That string appears nowhere in that file.** Their reader computes `DefinitionId = Path.GetFileNameWithoutExtension(targetFile)` before a byte is read; no element contributes to it. Same for `.dataset`, where `dsFibuErrorLog` is the identity and is not in the bytes. So even granting 1, 2 and 3, the bridge would have no candidate. ## Why this reframes the missing-path gap `extract(src_ptr, src_len, tree_ptr, tree_len)` gives the guest no path. That has been treated — including by me, one message earlier in the same conversation — as a limitation on *symbol coverage*: a package cannot emit a nice-to-have module symbol named after its file. It is not that. **It is what makes the highest-value cross-file relation in 1,323 files unresolvable in principle.** An entire class of formats works this way: identity from the filename, resolution by search path rather than by relative import. Definition files, resource dictionaries, config sets, typed-dataset descriptors. None of them can currently be linked to anything. ## The cheap fix, and why it does not disturb the fact protocol The reporter's proposal, and it is better than the obvious one. **Not the full path** — either the file STEM as a fourth input to `extract`, or an optional `TAG_FILE_SYMBOL` the guest may emit and the HOST validates against the real basename. The second keeps the host owning the string, the way `REL_QUALIFIERS` already works. And critically, it does not touch the byte-equality rule, because **symbols are already exempt from it**. `crates/abi/src/record.rs:920-927`, verbatim: > THE NAME MUST BE THE BYTES IT POINTS AT. Refs are checkable this way and symbols are not: a ref's span is always the name node's own, while a symbol's `decl` covers the whole declaration and its name may be normalised (an `impl Foo<T>` symbol is named `Foo`). So nothing in the fact protocol has to move. **The missing thing is an INPUT, not an output.** That is what makes this cheap enough to be worth doing. ## The second ask, recorded with its own counter-argument A non-proximity bridge scope — `project_wide` or `by_stem` — matching a destination anywhere in the project rather than in the same directory. The reporter raised it and argued against it in the same breath, which is why it is worth recording rather than dismissing: `dir = dir` is what keeps the join bounded, and an unscoped name match across a 10k-file repository is a cross-product with obvious phantom risk — almost certainly why `same_directory` was chosen. Their position: *"if the answer is 'no, and here is the cardinality that says why', that is a good answer I would record rather than re-litigate."* That is the right way to close it if it closes. But it should close with a measured cardinality, not with silence, because the class of formats it excludes is real and now has a number attached: four extensions, 1,323 files, in one repository. ## What a fix must prove * A package can emit a symbol named from its own file, and the host — not the guest — decides that name. A guest asserting a name the host did not derive must be refused. * A fixture where the identity string is **absent from the file's bytes**, which is the whole case. A fixture whose stem happens to appear in the content proves nothing. * The byte-equality rule for REFS is untouched; mutate it and the existing span/name tests must still go RED. * If `by_stem` is implemented rather than declined: the cardinality of the join measured on a 10k-file repository, and a phantom count, before it is enabled by default. ## Provenance Filed from an external package author's analysis of `bridges.rs`, `bridge.rs`, `index.rs` and `record.rs`. I verified reason 4's load-bearing claim (`record.rs:920-927`) directly; the other three cite lines whose content matches. Their own package ships with no bridges and is unaffected either way — as they put it, *"I would rather you heard this from a package author who went and read the SQL than from a bug report six months from now."*