[raeperd]

Stacked on #52. The diff shows only the Scan change.

Why

sql.Scanner requires a pointer receiver, the same as the Unmarshal methods that are already excluded:

Scan(src any) error

Value types that implement it are reported today. This includes the standard library's own types:

// database/sql
func (ns *NullString) Scan(value any) error
func (ns NullString) Value() (driver.Value, error)
// the methods of "NullString" use pointer receiver and non-pointer receiver.

On database/sql, github.com/google/uuid and github.com/shopspring/decimal, reports drop from 14 to 4. The 8 database/sql.Null* types, uuid.UUID and uuid.NullUUID are no longer reported.

What

• Add *.Scan to the built-in exclusions.
• Add an SQL type to the builtinmethods and disablebuiltin testdata.
• Set DisableBuiltin: true in the exclusions and exclusionswildcard tests. Their testdata is a Scan/Value pair, so the built-in Scan exclusion alone would make them pass without the user exclusion.
• README: list the new exclusion.

Trade-off

Scan is a more generic name than the Unmarshal* names, and exclusions match by name only. A type whose only pointer-receiver method is an unrelated Scan, such as Scan() bool, is no longer reported.

In the Go 1.27.3 standard library plus 49 popular modules, 32 types have Scan as their only pointer-receiver method. All 32 use the sql.Scanner signature.

Test

• go test -race . passes, and golangci-lint run reports 0 issues.
• With the analyzer.go change reverted, builtinmethods fails with an unexpected diagnostic on SQL.