Skip to content

Report the flag name as typed in deprecation warnings - #500

Open
hdimer wants to merge 1 commit into
spf13:masterfrom
hdimer:fix/deprecation-typed-flag-name
Open

Report the flag name as typed in deprecation warnings#500
hdimer wants to merge 1 commit into
spf13:masterfrom
hdimer:fix/deprecation-typed-flag-name

Conversation

@hdimer

@hdimer hdimer commented Jul 30, 2026

Copy link
Copy Markdown

Fixes #279.

With an alias from SetNormalizeFunc, using the alias for a deprecated flag printed the canonical name rather than the one typed:

--dir=test  ->  Flag --src has been deprecated, ...   # before
--dir=test  ->  Flag --dir has been deprecated, ...   # after

Parse's callback passed flag.Name into Set, so the typed name was gone before the warning was built. This threads the typed name through the internal parseFunc so the warning reports it. Long flags report the typed alias; shorthands keep the canonical long name (no alias to report). Public Set/ParseAll signatures are unchanged; calling Set directly with an alias now echoes that alias.

Added TestDeprecatedFlagUsageAlias.

Used AI assistance on this; I reviewed and tested it.

When a NormalizeFunc aliases a flag name, using the alias for a
deprecated flag printed the canonical name rather than the one the
user typed. Parse passed the normalized flag.Name into Set, so the
typed name was lost before the warning was built.

Thread the typed name through the internal parseFunc so the warning
reports it. Long flags report the typed alias; shorthands keep the
canonical long name. Public Set/ParseAll signatures are unchanged.

Fixes spf13#279
@CLAassistant

CLAassistant commented Jul 30, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@hdimer

hdimer commented Aug 30, 2026

Copy link
Copy Markdown
Author

Flagging that the red Lint here isn't this change.

golangci-lint v2.7.2 can't read Go 1.27's export data (export data version 4 is greater than maximum supported version 2), so every finding is a typecheck cascade off unresolvable stdlib imports — including errors.go:44:1: missing return for a function whose last statement is panic(...), which is a valid terminating statement. A genuine compile error there would have taken the test jobs with it; all six pass, 1.12 through stable.

Not asking anyone to fix the linter — just noting the PR isn't broken. Happy to rebase if a re-run would pick up a newer golangci-lint.

@tomasaschan

Copy link
Copy Markdown
Collaborator

Ah, thanks for flagging. I suppose we need to bump golangci-lint now that 1.27 is out, which rolls stable/oldstable build jobs one up.

PR welcome, otherwise I'll get to it when I get to it 😅

@hdimer

hdimer commented Sep 1, 2026

Copy link
Copy Markdown
Author

Opened #508 for the golangci-lint bump.

v2.13.2 is built with go1.27.0, which is what fixes the export-data read. One wrinkle: the bump also switches on govet's new inline analyzer, which wants reflect.Pointer over reflect.Ptr in three places — that needs Go 1.18 and go.mod still says 1.12, so I disabled the analyzer with a comment rather than touching the call sites.

Kept it to the version bump so it doesn't collide with #451.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MarkDeprecated and NormalizeFunc as alias results in an inconsistent deprecation message

3 participants