# 0178 — protocol impl method with a mismatched return/param TYPE silently miscompiles ## Symptom An `impl P for T` whose method has the right NAME but a mismatched return type or parameter type is accepted (it satisfies the issue-0176 conformance gate, which is name-based), and dispatch through the erased protocol silently produces the WRONG result (exit 0). No diagnostic. (Arity mismatch and `#builtin`-body mismatch fail loudly — exit 1 — and are not this bug; the TYPE-mismatch cases are silent.) ## Reproduction ```sx #import "modules/std.sx"; P :: protocol { val :: (self: *Self) -> i64; } T :: struct { n: i64 = 7; } impl P for T { val :: (self: *T) -> bool { return true; } } // return type bool ≠ i64 main :: () { t := T.{ n = 7 }; p : P = t; print("{}\n", p.val()); // prints "1" (the bool), silently wrong — no diagnostic } ``` A parameter-type mismatch (`x: bool` where the protocol declares `x: i64`) similarly dispatches silently wrong. ## Investigation prompt The issue-0176 conformance gate (`firstUnimplementedMethod` in `src/ir/lower/protocol.zig`) checks method PRESENCE (and rejects `type_params > 0`), but does NOT check that the impl method's SIGNATURE (parameter types, arity, return type) matches the protocol method's declared signature. A mismatched-type impl builds a thunk that calls the impl with the wrong ABI, silently miscompiling. Add signature validation when registering / gating an impl method against its protocol method: compare the impl method's params (after the erased `self`) and return type against the protocol declaration, and emit a located diagnostic on mismatch (arity, param type, or return type). The protocol method declaration is in `protocol_decl_map`; the impl FnDecl is in `fn_ast_map`. Decide whether this lives in the conformance gate or in `ProtocolResolver.registerImplBlock` (`src/ir/protocols.zig`). Follow the no-silent-fallback rule. Verify: the repro is now a clean diagnostic (exit 1); a correctly-typed impl still works; add an `examples/diagnostics/11xx-...` negative regression. (Found during adversarial review of issue 0176.)