[llvm-x86]

Fixes #155, built to the plan the maintainer approved on the issue.

Problem. A Kotlin call with a trailing lambda to let/run/with/apply/also is the stdlib scope function. Ripwire bound it to a Java method of the same name (s.run { } to Job.run).

Change.

• One per-call fact, Reference::trailingLambda, carried through RawRef, the cache record (+1 byte, kMinRefRecordBytes 60 to 61) and the quality mirrors.
• A Kotlin arm in FalseEdgeRules (FE-A) drops non-Kotlin candidates for these calls and reports external= when none is left. Kotlin candidates stay. Calls without a trailing lambda keep their edges.
• Typed receivers (b: lib.Builder then b.apply { }) skip receiver narrowing for these calls. Review found this case binding the Java method.
• Name table in externalnames.h with a javap provenance command and a sortedness static_assert. The Kotlin predicates sit in a LangFacts column (trailingLambdaScopeFns), so the langidentity ratchet does not rise.
• Gates: kotlincheck section 15, falseedgecheck arm J with fixtures. Walkers in cachefuzzcheck and pyimportprecisecheck follow the new record layout. Showcase capture regenerated.

Versions. kParserVer 228 and kCacheVersion 41 are placeholders; please renumber at landing. The qschemetrip re-pin is its own commit.

Known floors (changelog fragment): parenthesised lambdas are not covered; a Java method of a scope-function name called from Kotlin with a trailing lambda is dropped; a qualified kotlin.run { } can still bind an in-tree Kotlin run.

Checks. Three reviewers; the one real bug is fixed. Full suite on Linux (g++-14): the failures left were load timeouts and missing tools, and the suspect gates pass alone.

Summary by CodeRabbit

• Bug Fixes

  • Kotlin calls to let, run, with, apply, and also with a trailing lambda no longer incorrectly match same-named Java methods. Kotlin candidates are retained, and calls without a matching Kotlin target are reported as external.
  • Calls without a trailing lambda, calls with a parenthesized lambda, and Kotlin-defined run retain their existing behavior.

• Documentation

  • Added guidance on how Kotlin trailing-lambda scope-function calls are resolved.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: redhat-et/ripwire
• Branch: main
• File: .coderabbit.yaml
• Commit: 0b2734a
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 66e89ca0-623d-443a-8532-06081c887f01

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: redhat-et/ripwire
• Branch: main
• File: .coderabbit.yaml
• Commit: 7abad95
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 364897ce-1cd1-4986-9c0f-62d0a317cd9d

Commits

Reviewing files that changed from the base of the PR and between 7abad95 and 709991f.

Files ignored due to path filters: 10

• docs/captures/COMMANDS_showcase_2026-10-25.md is excluded by !docs/captures/**
• test/falseedgefix/README.md is excluded by !test/*fix/**
• test/falseedgefix/kt/java/jobs/Job.java is excluded by !test/*fix/**
• test/falseedgefix/kt/java/lib/Builder.java is excluded by !test/*fix/**
• test/falseedgefix/kt/kt/Dispatch.kt is excluded by !test/*fix/**
• test/falseedgefix/kt/kt/Scopes.kt is excluded by !test/*fix/**
• test/falseedgefix/kt/kt/Use.kt is excluded by !test/*fix/**
• test/falseedgefix/ktown/java/jobs/Job.java is excluded by !test/*fix/**
• test/falseedgefix/ktown/kt/Task.kt is excluded by !test/*fix/**
• test/qschemetrip.hash is excluded by !test/*.hash

Files selected for processing: 16

• changelog.d/155-kotlin-scope-functions.md
• docs/ARCHITECTURE.md
• src/externalnames.h
• src/graph.h
• src/ingest_cache.h
• src/ingest_metrics.h
• src/ingest_model.h
• src/ingest_sidecap.h
• src/langfacts.h
• src/model.h
• src/quality.h
• test/cachefuzzcheck.sh
• test/falseedgecheck.sh
• test/kotlincheck.sh
• test/pyimportprecisecheck.sh
• test/qschemetripcheck.sh

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

Walkthrough

Kotlin calls to let, run, with, apply, and also with trailing lambdas now filter same-named Java candidates. Kotlin candidates remain, or the call is reported as external if none remain. The change captures and persists trailing-lambda syntax and adds resolution and cache tests.

Changes: Kotlin scope-function resolution

Layer / File(s)	Summary
Capture and persist trailing-lambda syntax src/langfacts.h, src/model.h, src/ingest_metrics.h, src/ingest_sidecap.h, src/ingest_model.h, src/ingest_cache.h, src/quality.h, test/cachefuzzcheck.sh, test/pyimportprecisecheck.sh, test/qschemetripcheck.sh	Kotlin language facts enable detection of a direct trailing lambda. The flag is transferred to references and added to cache records. Cache and parser versions and cache-layout checks are updated.
Filter scope-function candidates src/externalnames.h, src/graph.h, docs/ARCHITECTURE.md, changelog.d/155-kotlin-scope-functions.md	A sorted name table identifies the five scope functions. Graph resolution filters non-Kotlin candidates for matching trailing-lambda calls before receiver checks and skips later receiver narrowing for those calls. The documentation describes the behavior and stated limits.
Validate resolution and cache behavior test/kotlincheck.sh, test/falseedgecheck.sh	Kotlin fixtures check candidate bindings, external census rows, Java caller and map stability, mutation behavior, deterministic cache output, and XML validity.

Priority: Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: joyful-ii-v-i

Merge Risk: Minimal · up to 70999

No actionable issue is established for this change. Merge after the normal required checks.

Pre-merge checks: 4

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title "fix(kotlin): a trailing-lambda scope function never binds a Java method (#155)" matches the main change. The changeset adds a per-call trailing-lambda flag and a Kotlin false-edge rule. Tha…
Linked Issues check		Issue #155 coding requirements, from the issue body and the current PR description: 1. Remove false Java edges for Kotlin trailing-lambda calls to run, let, apply, also, with. Met. The Kotlin arm in …
Out of Scope Changes check		Every included change ties to the #155 trailing-lambda fix: - Core behavior: Reference::trailingLambda (model.h), RawRef and cache record (ingest_cache.h), emitReferences copy (ingest_model.h), kotli…

Full details: Title check

Explanation

The title "fix(kotlin): a trailing-lambda scope function never binds a Java method (#155)" matches the main change. The changeset adds a per-call trailing-lambda flag and a Kotlin false-edge rule. That rule drops Java method candidates for trailing-lambda calls to let, run, with, apply, and also, and it keeps Kotlin candidates. The title names the Kotlin scope-function scope and the Java-binding fix. It also carries the conventional fix(kotlin) prefix and the issue reference #155. The title is accurate and specific, and it fits a teammate scanning history.

Full details: Linked Issues check

Explanation

Issue #155 coding requirements, from the issue body and the current PR description:

1. Remove false Java edges for Kotlin trailing-lambda calls to run, let, apply, also, with. Met. The Kotlin arm in FalseEdgeRules (FE-A) drops non-Kotlin candidates for these calls. The rule runs before the receiver gate. Typed receivers skip receiver narrowing for these calls.
2. Keep Kotlin candidates. Met. Kotlin candidates survive the filter. A Kotlin-defined run stays a candidate, and kotlincheck section 15 is described as checking this.
3. Report unbound sites as external. Met. When filtering leaves no candidate, the call resolves to external=. Refused sites appear in the external census.
4. Preserve the real block.run() edge on a Runnable. Met by construction. The per-call fact is set only when kotlinTrailingLambda finds an annotated_lambda under call_suffix. Calls without a trailing lambda keep their edges. Section 15 includes a mutation that removes the trailing lambda and checks that the Java edge returns. The fixtures that hold the Runnable case are in excluded paths (test/falseedgefix/**), so their run results are not independently verified. The rule gate alone establishes the behavior.
5. Cached per-call-site fact in the reference record. Met. Reference::trailingLambda is carried through RawRef, writeRef and readRef (one byte, kMinRefRecordBytes 60 to 61). The quality mirrors and walkers in cachefuzzcheck and pyimportprecisecheck follow the new layout.
6. Sorted name table in src/externalnames.h. Met. kKotlinScopeFunctionNames holds also, apply, let, run, with. A compile-time sortedness and uniqueness check and an isKotlinScopeFunction binary search are added.
7. Version bumps, mirrors and pins. Met. kParserVer 224 to 228 and kCacheVersion 39 to 41, with mirrors in quality.h. A re-pin log entry is added in qschemetripcheck.sh. The PR states that 228 and 41 are placeholders.
8. Kotlin test section in test/kotlincheck.sh. Met. Section 15 is added.

Not assessed as a coding requirement: the measurements on retrofit, nowinandroid and ktor. They are verification runs, not code. The PR does not report them. The issue prompt (prompts/help-wanted/kotlin-scope-functions.md) is not in the supplied evidence. No requirement from it is assessed.

Known limits stated in the PR (parenthesized lambdas, Java scope-name methods called with a trailing lambda, qualified kotlin.run) are not in the issue's stated requirements, so they do not fail this check.

Full details: Out of Scope Changes check

Explanation

Every included change ties to the #155 trailing-lambda fix:

• Core behavior: Reference::trailingLambda (model.h), RawRef and cache record (ingest_cache.h), emitReferences copy (ingest_model.h), kotlinTrailingLambda helper (ingest_metrics.h), C++ capture gated by langFacts trailingLambdaScopeFns (ingest_sidecap.h, langfacts.h), name table (externalnames.h), FE-A rule (graph.h).
• Required version and mirror updates: quality.h mirrors, parser and cache version constants, cache walkers in cachefuzzcheck.sh and pyimportprecisecheck.sh, re-pin log in qschemetripcheck.sh.
• Tests and docs for the feature: kotlincheck.sh section 15, falseedgecheck.sh arm J, changelog fragment, ARCHITECTURE.md section.
• Showcase capture regeneration (docs/captures, ignored path): a generated artifact of the behavior change. Its contents were not inspected because the path is excluded. Its absence or presence does not change this verdict.

The Java-edge loss for same-named Java methods called from Kotlin with a trailing lambda is the intended effect of the rule. The PR discloses it as a known floor. It is not an unrelated change.

The qschemetrip.hash re-pin is described as a separate commit. The hash path is excluded and was not inspected.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

_{Comment @coderabbitai help to get the list of available commands.}

[llvm-x86]

CI note: the only failure on the last run was cppqualcheck on macos-26 (shard 3/4), a 30 s alarm on two --uses queries while the runner was heavily loaded (3100 s wall). It is not related to this change. I cannot rerun jobs, so I pushed again to start a fresh run.

[joyful-ii-V-I]

Thank you @llvm-x86. This is a careful piece of work, and it follows the #155 plan closely: one per-call fact, an FE-A arm instead of a new standalone rule, a name table with a regenerating javap command, and the qschemetrip re-pin in its own commit. We checked a lot of it on macOS (AppleClang dev build and an llvm@22 ASan build, both at 4438f152), and what you describe works:

• kotlincheck §15, falseedgecheck arm J, cachefuzzcheck, pyimportprecisecheck, qschemetripcheck and langidentitycheck all pass. The first four also pass under ASan with no reports. The langidentity ratchet stays at 335: putting the predicate in a LangFacts column worked.
• The arms can fail. We dropped r.trailingLambda from the decide condition, so the rule matched on the name alone. 15b, 15i and 15k went red, and so did falseedgecheck (kt) Job.java:run.
• The cases you named are handled: s.run { }, with( sb ) { }, s?.let { }, xs.also { }, and a typed b.apply { } on a Java Builder all go to external= with a census row. Labelled (s.run lbl@{ }), annotated, chained (s.let { }.run { }), type-argument (s.let<String, Int> { }), bare run { } and kotlin.run { } sites go to external= as well. They no longer bind Job.run/Job.let. j.let()/j.also() without a lambda keep their edges. An in-tree Kotlin extension fun <T> T.run(...) keeps its caller. A parenthesised lambda keeps its edge, the floor you disclosed.
• The record layout moves together. writeRef/readRef add the byte in the same place, kMinRefRecordBytes is 61 and the tripwire agrees, and a cache from main (c40p226) is not read, so the warm answer equals the cold one. The Java-invariant arm (§14c pattern) and the presence-before-absence --match arms are a nice touch.
• Outside the change, 31 argv over 7 repos are byte-identical to main (--top-k, --hotspots, --pin-census, --dead-code, envoy --callers=run/apply/let/also/with). The envoy and codanna census files are identical too: envoy's 19 trailing-lambda scope calls have no Java namesake that could bind.

Three things came out of review, and we made all of them as commits on top of your head so you don't have to. We pushed them to your fix/155-kotlin-scope-fns through maintainer edits. One commit per item:

1. c64e76d9: a Kotlin-typed receiver lost its proof (regression). Every receiver rule was skipped for these calls, including when the receiver's type is a Kotlin class that defines the method. In a Kotlin-only tree with class Task { fun run(block: () -> Unit) } and class Other { fun run(...) }, fun go(t: Task) = t.run { } and val o = Other(); o.run { } each bound their own class's run on main, and at 4438f152 both split over both with via="name". Your own tree C showed it too (go -> Task.run went from receiver-rule to via="name"; §15g compares names only, so it didn't catch it). The fix keeps Rule 2 and FE-B receiver evidence running, and undoes the pick only when it holds a non-Kotlin candidate, so FE-A decides exactly the calls the PR targets. Two red-first arms: 15l (the tree above, typed and constructed receivers) and 15m (tree C's go row has no via="name"). They are red at 4438f152 and green with the fix. The other §15 arms, arm J, and our probes for typed Java receivers, fields, constructed receivers and class-name receivers still give external=. The same commit rewords the floors: "a receiver of a Java type is not checked", and the qualified kotlin.run { } floor (it can still bind an in-tree Kotlin run, hedged) is now in the changelog and ARCHITECTURE too.

2. 9f63bb51: --quality-delta 0b2734a7..HEAD gated (3). kKotlinScopeFunctionNames is now asserted by the existing isStrictlySortedTable, and kotlinTrailingLambda reads call_suffix then annotated_lambda with firstChildOfKind (infra/tschildren.h). One one-line idiom clone is left (inSortedTable ~ isMarkdownGrammarExtension; no shared helper fits two tables in two headers), and we acked it with a reason. The range now gates 0.

3. 24d85548: dropped the showcase capture and the docs/COMMANDS.md regen. They were generated from a checkout at /w, and the generator's path scrub replaced every /w with . (src.rap for src/wrap…, .github.orkflows, read.rite, which.hy, do.hile, test/planlintfix.ave, about 36 spans in the capture and 25 in docs/COMMANDS.md), and the scratch dir sat inside the repo. That is our generator's bug, not yours, and we'll fix the scrub. Both files are back to the base state in this commit, and we regenerate the capture on the merged tree when this lands (so showcasecapturecheck is red on the branch until then; that is expected).

After these commits, at the new head, on macOS (AppleClang dev build, plus an llvm@22 ASan build for the first two): kotlincheck, falseedgecheck, cachefuzzcheck, pyimportprecisecheck, qschemetripcheck, langidentitycheck, printffmtparitycheck and changelogfragcheck pass, with no sanitizer reports. 31 argv over seven repos are still byte-identical to main.

Still open, for you or a follow-up:

• The quality.h mirror comments lost their 40 = train 34 and 226 = 2026-10-24 history lines. We restore them when we renumber at landing.
• A design question, not a blocker. With a trailing lambda, a Java candidate whose declared arity is 0 provably cannot be the target, like Job.run(), Builder.let(), Builder.also(). A Java method with a parameter could be a SAM call (e.run { } on Exec.run(Runnable) bound correctly on main and is now external=). Did you consider dropping only the arity-0 Java candidates and hedging the rest? That would turn the disclosed floor into a hedge. Fine to leave it for a follow-up.

Versions: we renumber kParserVer/kCacheVersion (and the pyimportprecisecheck walker's == 41) at landing above train 35, and redo the qschemetrip re-pin then. This lands in the train after #432. #437 touches src/langfacts.h and the qschemetrip pin as well, and we'll resolve that at the train. Thanks again. This closes a false-edge class we've wanted closed since the kit.

[llvm-x86]

Thank you for the review and the three commits. I will not push to this branch again.

About the capture: that was my fault. I generated it in a /w checkout and did not check the path scrub. Dropping both files was the right fix.

About the arity-0 question: I did not consider it, and I think it is the better design. A Java candidate with no parameters cannot be the target of a trailing-lambda call. A candidate with a parameter can be (Exec.run(Runnable)). So dropping only the arity-0 candidates and hedging the rest turns the floor into a hedge, and it brings back the e.run { } edge that main had. I agree it is a follow-up, not a blocker. I can open it as a separate issue or PR on top of this one after it lands, if you want.