Skip to content

L2 gets an exit criterion, because the measurement gave it one - #256

Closed
milyin wants to merge 2 commits into
language-integrationfrom
docs-l2-plan
Closed

L2 gets an exit criterion, because the measurement gave it one#256
milyin wants to merge 2 commits into
language-integrationfrom
docs-l2-plan

Conversation

@milyin

@milyin milyin commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Docs only. Rewrites the L2 section of docs/language-integration.md, which #229's body mirrors.

The section was a by-file checklist written before the stage was investigated, and it inherited the map's default assumption — that some sites stay because they inspect types the adapter synthesized.

The measurement

Instrumented Registry::ensure_entry (the one place a type-table cell is born) across example-cbindgen, covertest-kotlin, perftest-c and perftest-kotlin. TypeSubject::Adapter has two members:

Cell Where it came from
MaybeUninit<Payload> source writes &mut MaybeUninit<Payload>; the scan peels the &mut syntactically. The model absorbed MaybeUninit into RefMode::Out, so it has no node for the peeled spelling — and the cell resolves to no converter
Option<Summary> source writes Option<&Summary>; the peel family strips the & inside the Option and re-composes a spelling nothing wrote

Neither is a type a binding invented. Both are manufactured by the syntactic peeling L2 deletes, and both underlying types are ordinary source types.

Corroborating that the category has no genuine members: unfold.rs, expand.rs and registry/walk.rs contain zero mentions of TypeEntry or a wire type, so the "legitimately the adapter's business" exemption has no members in this stage — all 45 sites classify source types. The .cross() path, which the code comments describe as the adapter-authored one, is exercised by covertest-kotlin and produced no cells either.

Measured in-tree only, stated as such in the doc — the same shape of claim #248 makes about fallible_parts logging zero. zenoh-flat's consumers are out of tree and do not currently build.

What the section now says

An exit criterion ahead of the checklist, because it is stronger than a count and is what each PR reports against:

TypeSubject::Adapter reaches zero members, and the variant is deleted.

TypeCell's subject collapses to the TypeRef; location() becomes origin.location gated by the existing has_position(), and kind() — already #[cfg(test)] — goes with it. Two production readers, both in resolve.rs.

Then five PRs summing to exactly 45:

Owns Sites
L2a the scan walks model edges 13
L2b one layer read 26
L2c the enum shape and its numbers 2
L2d canonicalization moves home 4
L2e delete TypeSubject::Adapter 0

Each says whether it migrates a site or deletes the code holding it — L2a drops three dead arms (lower_type refuses tuples and raw pointers; Group/Paren are transparent; named() drops generic args by design), and L2d is labelled a move, not a migration, the same distinction #248's deletions get.

L2b and L2c also close two of the ledger header's listed blind spots by removing the code: the seg.ident == "Option" family, and enum_shape / first_payload_variant, which take a syn::ItemEnum that WATCHED cannot see.

Not changed

No counts move — this records the plan, not progress. The #248 is deletion, not migration note stays, and the older TypeKey-from-a-TypeRef bullet is folded into L2b rather than dropped.

milyin added 2 commits August 1, 2026 01:32
The L2 section was a by-file checklist written before any of the stage was
looked at, and it carried the map's default assumption: that some sites
must stay because they inspect types the adapter synthesized.

Instrumenting ensure_entry across every in-tree example says otherwise.
TypeSubject::Adapter has two members, both manufactured by the syntactic
peeling L2 deletes: MaybeUninit<Payload>, which the model absorbed into
RefMode::Out and which resolves to no converter at all, and Option<Summary>,
where the source wrote Option<&Summary>. Neither is a type a binding
invented. Nothing in unfold, expand or registry/walk mentions a wire type,
so the adapter-synthesized exemption has no members in this stage.

So the stage gets a criterion stronger than a count: the variant reaches
zero members and is deleted. The five PRs sum to exactly 45, and each says
whether it migrates a site or deletes the code holding it -- the L2d move
is labelled a move, the same way #248's deletions are labelled deletions.
…l it

Counted the callers before starting L2a rather than after, and the split I
wrote does not survive it. Every classifying helper in types_util has
adapter callers -- option_inner_type 40, bare_path_ident 22, is_unit 18,
first_type_arg 14, is_option_type 13 -- and none takes an &Flat, so it
cannot consult the model from the inside either. L2 can stop api/core from
calling them; only L3 and L4 can free them to be deleted.

So L2a is 11 (not 13, the ident extractors cannot come along), L2b is 20
(not 26, the peel family stays), and L2c moves 0 rather than 2. L2d keeps
its 4 because normalize_type and type_from_ident are the only two helpers
in the file with no adapter caller at all -- which is what makes them
movable while the other ten wait.

api/core therefore ends the stage at 10, and the table naming them says so.
That is what the rule about each entry's fate asks for: the ones that stay
are named, and their reason is a dependency rather than a verdict.
@milyin

milyin commented Aug 1, 2026

Copy link
Copy Markdown
Owner Author

Closing unmerged: the stage plan belongs in the umbrella PR description and in #211, not in a file in the repo.

The measurement and the L2a–L2e split it produced are carried over to #229's body and to #211's text, so nothing in it is lost. The two corrections it also carried — the ledger standing at 167 rather than 202, and the caller counts that make L2 end at 10 sites rather than 0 — go with them.

Superseded by the description updates on #229 and #211.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant