Redefine Builtin Id
ID |
go.redefine_builtin_id |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Reliability |
Language |
Go |
Tags |
reliability, suspicious |
Description
Reports a declaration whose name shadows a Go predeclared (built-in) identifier — a type
(int, string, error, …), a constant (true, false, nil, iota) or a built-in
function (len, cap, copy, append, …).
Rationale
Go permits redeclaring a predeclared identifier, so the code still compiles, but within the new
scope the original meaning is gone. After var len = 0 the call len(s) no longer compiles; after
const true = 0 the literal true is an integer. These shadows read as ordinary code yet behave
in surprising ways, and they are a frequent source of subtle, hard-to-find bugs.
func len(x int) int { return x } // FLAW — shadows the builtin len
var string = "x" // FLAW — shadows the builtin type string
const true = 0 // FLAW — shadows the builtin constant true
var count = 0 // OK — not a predeclared identifierRemediation
Rename the declaration to a name that is not predeclared (length, text, enabled, …). The
fix is mechanical and the built-in regains its normal meaning everywhere in scope.