A teammate's HTML-style DSL compiles, but a tag added inside an inner block mysteriously attaches to the outer element. Diagnose how implicit receiver resolution causes this, and give two concrete fixes.

## The symptom A nested builder where content written in an inner block ends up on the outer element. It compiles cleanly, runs, and produces wrong structure — the worst kind of DSL bug. ## Root cause: fall-through to an outer receiver Unqualified resolution searches the implicit receivers **innermost → outermost** and binds to the **first receiver that has the member**. If the inner receiver type does **not** declare the called builder method but the outer one does, the call legitimately resolves to the **outer** receiver. The lambda is the inner block, but the method runs against the outer object — so the new tag is appended to the outer element. ```kotlin class Table { fun row(b: Row.() -> Unit) { /* ... */ } ; fun cell(t: String) { /* on Table! */ } } class Row { /* note: no cell() here */ } fun table(b: Table.() -> Unit) = Table().apply(b) table { row { cell("oops") // Row has no cell(); falls through to Table.cell -> wrong element } } ``` Because `Row` lacks `cell`, `cell("oops")` resolves against `Table`, attaching the cell to the table, not the row. ## How to diagnose 1. Identify the receiver types at each nesting level (the lambda receiver types). 2. Check **which type actually declares the called method**. If it's only on the outer type, you've found the fall-through. 3. Optionally make it explicit: temporarily write `this.cell(...)` or `[email protected](...)` — if `[email protected]` fails to compile, that confirms `Row` doesn't have it. ## Fix 1 — give the inner type the member Add `cell` to `Row` so the inner receiver matches and resolution stays inner: ```kotlin class Row { fun cell(t: String) { /* on Row */ } } ``` ## Fix 2 — @DslMarker to forbid silent outer calls Mark the receiver types with a `@DslMarker` annotation. The compiler then **rejects** an unqualified call that would bind to an *outer* receiver of the same marker, converting the silent fall-through into a compile error: ```kotlin @DslMarker annotation class HtmlTagMarker @HtmlTagMarker class Table { fun cell(t: String) {} ; fun row(b: Row.() -> Unit) {} } @HtmlTagMarker class Row table { row { cell("x") } } // now: compile error -> 'cell' is an outer-receiver call ``` The developer must then add `cell` to `Row` (the real fix) or explicitly write `[email protected]("x")` if attaching to the table was actually intended. ## Why @DslMarker is the durable answer Adding the missing member fixes one case; `@DslMarker` prevents the *entire class* of accidental cross-level calls for every method across the DSL. Production DSLs (kotlinx.html, Gradle Kotlin DSL) apply it precisely for this reason. ## Recap of the mechanism - Inner-first search + fall-through = outer receiver can be hit silently. - It compiles because the outer member is genuinely applicable. - Guard with `@DslMarker`; intentional outer access uses `this@Label`.