The previous default (atomic.Bool zero-value = enabled) meant any
*cobra.Command built without first calling configureFlagCompletions
leaked into cobra's package-global flagCompletionFunctions map. Bench
runs (scripts/bench_build) showed hundreds of KB and thousands of
objects retained per Build call.
Flip the semantics so the zero-value matches the safe default:
- Rename internal var to flagCompletionsEnabled (zero = disabled).
- Rename public API to SetFlagCompletionsEnabled / FlagCompletionsEnabled.
- Update call sites in cmd/root.go and scripts/bench_build/main.go.
- Add cmd.TestBuild_DefaultNoCompletionLeak: asserts that, with no
setter call at all, repeated cmd.Build invocations stay under 50 KB
and 500 objects per build (observed: ~0.7 KB, 3 objs/build). This
closes the gap that let the wrong default ship — every previous
test explicitly Set the switch before exercising it.
Change-Id: Ifefb04af5fd45eea9676a344a64ad071b6a4cd1a
* fix: skip flag-completion registration outside completion path
Cobra keeps completion callbacks in a package-global map keyed by
*pflag.Flag with no removal path, so registrations made during Build()
outlive the command itself. Route all seven call sites through
cmdutil.RegisterFlagCompletion and enable registration only when the
invocation actually serves a __complete request.
Measured over 30 dropped Builds: ~202 KB / 2180 retained objects per
Build before, ~0 after.
Change-Id: I734d598a4c91a92c33b02e0f292f640cc0e224c6