fix(registry): recognize C# lower-case type keywords in receiver_chain_admits - #2170

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Both red legs here (test-windows CLANG64 timing race, and the downstream shard-completeness failure that depends on it) are outside this diff, neither touches registry.c or test_pipeline.c. Been open a week with no look yet, let me know if anything's blocking review.

Thank you for the C# keyword fix and negative controls. The current registry's lower-case receiver handling supports the reported gap. Review should preserve the C# keyword cases without admitting unrelated receiver names in other languages. We still need to attribute the Windows failure from its evidence; an unchanged Windows-specific file list alone would not prove it unrelated. The contribution is queued for that focused review.

Read the job log rather than the file list this time. The windows-latest CLANG64 leg fails inside tests/test_parallel_harness_contract.sh's own scheduler self-test, step 0i: "FAIL: Windows timeout race refused without a surviving descendant to refuse over, the fixture no longer exercises the race" (job 103034332390). That's a timing fixture for the test harness's own process cleanup, nothing in registry.c or test_pipeline.c. shard-completeness and ci-ok both fail downstream of that missing shard manifest (job 103051948933 shows no manifest uploaded for windows-latest-CLANG64-0).

Fixed and pushed (1ebd1e4). The lint job's clang-format check was failing on the three new cbm_registry_resolve_lang call sites, all over the 100-column limit. Reproduced with clang-format 18 and 20 against the repo's own .clang-format, re-wrapped, confirmed clean with a dry-run diff. Whitespace only, no token changes.

Thank you, @AmirF194, for this fix and for your patience while main moved under it. Your diagnosis was exactly right: receiver_chain_admits let every lower-case receiver root through as a value, and C# spells its built-in types as lower-case keywords, so int.TryParse(...) skipped the chain check and could bind to any project method named TryParse. The closed, C#-only keyword list is the right shape, and your three tests (the refusal, the matching-chain true positive and the non-C# control) carried straight over. The open review points were already settled and the branch allows maintainer edits, so we finished them here instead of asking you for another round.

What we changed, on top of your commits (which are untouched):

1. Merged current main in (one merge commit). main had meanwhile added its own cbm_registry_resolve_lang(..., CBMLanguage lang) under the same name as this branch's bool is_csharp version, and both CALLS resolvers now reach the registry through one entry point, cbm_registry_resolve_call_scoped. Seven files conflicted. We resolved all seven to main's side, because main's language parameter replaces the is_csharp threading.
2. The keyword gate now uses main's CBMLanguage. cbm_registry_resolve_call_lang passes the calling file's language down to receiver_chain_admits, which applies your keyword list only for CBM_LANG_CSHARP. Both resolvers share that one entry point, so the sequential and parallel paths cannot drift apart, and the production change is confined to registry.c (plus one comment in pipeline_internal.h). Every non-CALLS resolve passes no language, so USAGE, THROWS/RAISES, READS/WRITES, INHERITS, DECORATES and route-handler lookups behave exactly as before, as the earlier review asked. Extending the gate to them is welcome as its own PR.
3. nint and nuint joined the list (C# 9 native-sized integers, as in nint.TryParse).
4. The per-file resolve cache records the C# bit, so a C# call and a C# reference to the same name never share one cached answer.
5. Your three unit tests call the CALLS entry point with a real language (C#, Python and Go) instead of a bool, and the refusal test also covers nint.TryParse.
6. A new end-to-end test, parallel_csharp_keyword_receiver_no_name_guess_issue2121, indexes the two files from BCL/external calls fabricate CALLS edges to unrelated internal classes (phantom callers; e.g. int.TryParse → internal TryParse) #2121 with both the sequential and the parallel pipeline: no CALLS edge from int.TryParse or nint.TryParse to TsidNode.TryParse, while TsidNode.TryParse(...) still binds.

How we checked it: the new end-to-end test and your refusal test fail on main (the fabricated edge shows up in both pipelines) and pass with the change. The pipeline, registry, parallel, cs_lsp, convergence_probe and matrix_new_constructs suites pass. cppcheck 2.20, clang-format 20, the NOLINT check and the memory-core ratchet are clean. The issue's own two files no longer produce the Demo.M -> TsidNode.TryParse edge. On four libraries from dotnet/runtime (about 1,700 C# files), the change removes 68 fabricated CALLS edges and adds none. Examples are string.Format bound to a project's DecimalFormatter.Format and char.IsWhiteSpace bound to XmlCharType.IsWhiteSpace. The sequential and parallel results are identical.

One limit to be aware of: when several project methods share the name and the file has using imports, the registry takes a different path that never consults the receiver chain, in any language. Fixing that is a separate, wider change, so it stays out of this PR.

We will merge once CI is green on the new head. Thank you again for the careful work and the clear write-up!

Thank you again for the C# keyword guard and controls. The October 20 update records the language-parameter adaptation and end-to-end coverage as completed on our side. Sorry for the delay in the remaining maintainer follow-up—I’ll follow up soon.

Thank you again, @AmirF194, and sorry this took longer than the "soon" we promised on October 25. Your fix has held up well: on current main, int.TryParse(...) in a C# file can still bind to any project method named TryParse, and your keyword gate is still what stops it.

We pushed two more commits on top of your branch (your commits are untouched):

1. dynamic left the keyword list. int, string, object and the other reserved type keywords can only ever name the built-in type, and nint and nuint name it in practice too. dynamic is different: it is a contextual keyword, and the dynamic type has no static members, so in receiver position it is a variable that happens to be called dynamic. Such a receiver now follows the ordinary value-root rule again, like any other lower-case variable. We checked this on dotnet/runtime: all 586 nint. and nuint. member accesses there are static members of the built-in types (Size, MaxValue, Parse, TryParse, ...), while none of the 10 dynamic. receivers is the built-in type: nine are variables named dynamic, and one is a test enum declared as @dynamic. A new C# test pins it: a call through a variable named dynamic still binds.
2. Merged current main in (one merge commit). Two spots needed care: main added two C# tests to tests/test_parallel.c at the same place as this branch's end-to-end BCL/external calls fabricate CALLS edges to unrelated internal classes (phantom callers; e.g. int.TryParse → internal TryParse) #2121 test, and all three are kept; and main gained a new Swift caller of receiver_chain_admits, which now passes its language like the other callers. Swift behaves exactly as before, since the keyword list applies to C# only.

How we checked it: the new dynamic test fails with dynamic still on the list and passes without it, and your refusal, matching-chain and non-C# control tests still pass. After the merge, the pipeline, parallel, registry and cs_lsp suites pass under AddressSanitizer and UndefinedBehaviorSanitizer, including the Swift tests that go through the adapted caller. The two files from #2121 still lose the Demo.M -> TsidNode.TryParse edge, while TsidNode.TryParse(...) still binds. On four dotnet/runtime libraries (System.Private.Xml, System.Data.Common, System.Formats.Asn1 and System.Runtime.Numerics, 1,611 C# files), the branch removes 26 CALLS edges compared with main and adds none, and the sequential and parallel pipelines build identical results. We read all 26: each one was a static call on a built-in type that had been bound by name to an unrelated project method, for example char.IsAsciiDigit to XPathScanner.IsAsciiDigit, decimal.GetBits to DataStorage.GetBits and double.IsNaN to BigInteger.IsNaN.

One correction to our October 19 note: the C# LSP change for #1692 that we said would complement this PR is not going ahead for now, so your registry-side check is what fixes this part of #2121.

If you push to this branch again, please pull first, since it now has our commits on top. We will merge once CI is green. Thank you for the careful work and the clear write-up!