Motivation: add a check for a common issue I see humans and AI agents
making, so that we don't have to waste time on it in code reviews.
Resolves#42635
Note: This lint check has been mostly AI generated. I don't think it
needs a thorough review because it is not production code and not even
test code. Any issues will be obvious from usage by contributors.
Add a custom go/analysis analyzer that detects map[T]bool variables
used as sets (where only the literal `true` is ever assigned) and
suggests using map[T]struct{} instead, which is the idiomatic Go
approach for sets — zero memory for values and unambiguous semantics.
The analyzer minimizes false positives by:
- Only flagging when ALL indexed assignments use the literal `true`
- Skipping variables initialized from function calls (unknown source)
- Skipping variables reassigned from unknown sources
- Skipping function parameters and exported package-level variables
- Skipping range loop variables
Integrated as an incremental linter (new/changed code only) to avoid
breaking existing code.
Running this check on our whole codebase flags valid cases:
```
cmd/fleet/serve.go:306:2: map[string]bool used as a set; consider map[string]struct{} instead (setboolcheck)
allowedHostIdentifiers := map[string]bool{
^
cmd/fleetctl/fleetctl/generate_gitops.go:189:3: map[string]bool used as a set; consider map[string]struct{} instead (setboolcheck)
handled := make(map[string]bool, len(renames)*2)
^
cmd/fleetctl/fleetctl/generate_gitops.go:1593:2: map[uint]bool used as a set; consider map[uint]struct{} instead (setboolcheck)
m := make(map[uint]bool, len(ids))
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Added a new code analyzer to detect maps used as boolean sets and
recommend more efficient alternatives for better performance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Scott Gress <scottmgress@gmail.com>
Co-authored-by: Scott Gress <scott@fleetdm.com>
