ifacereturn

Overview ¶

Command ifacereturn reports every function and method result in a Go module through which an interface reaches a caller — the result's own type, or an interface-typed field of a struct it hands back.

Running it ¶

In this monorepo, through the CLI:

candace style ifacereturn

That wraps tools/check-ifacereturn.sh, which knows where the modules are and runs this command in the pinned toolchain container. It is the invocation an operator here should use; the raw one below exists for the other audience.

It is the flagging lane of house rule CS-8. The blocking lane is a separate lexical gate, narrow by design, that fails CI. This one is type-aware and as wide as the rule's headline sentence: methods included, stdlib and third-party interfaces included, `any` included, `error` excluded. It exits 0 with findings printed, because most of what it reports has already been ruled correct and a gate whose findings have no fix is one people learn to route around.

For consumers of the published candacelabs/csf module, who have no private CLI, the portable invocation is a go run from a module root:

go run github.com/candacelabs/csf/tools/ifacereturn/cmd/ifacereturn ./...

or, for the two-module sweep CI does, build it once and run the binary from each module root. `-strict` exits 1 when anything is reported, so the lane can be made blocking later without changing the tool; it is not what CI passes today.

Exit codes are three, and the third is the point: 0 scanned and reported, 1 scanned and reported under -strict, 2 could not scan (a load error, or no packages at all). A scanner that cannot read its corpus must not be able to print "0 findings" — that is the vacuous pass this repository keeps rediscovering.