[log] Add debug logging to custom linter analyzers

[github-actions]

Summary

Adds structured debug logging to five custom Go linter analyzers using the shared pkg/logger package. No logic changes; this is a pure observability improvement.

Changes

File	Logger name
pkg/linters/deferinloop/deferinloop.go	linters:deferinloop
pkg/linters/excessivefuncparams/excessivefuncparams.go	linters:excessivefuncparams
pkg/linters/httprespbodyclose/httprespbodyclose.go	linters:httprespbodyclose
pkg/linters/httpstatuscode/httpstatuscode.go	linters:httpstatuscode
pkg/linters/largefunc/largefunc.go	linters:largefunc

Each analyzer receives:

• A package-level var log = logger.New("linters:<name>") logger.
• A log.Printf("analyzing package %s", pass.Pkg.Path()) call at the start of run(). Configurable-threshold analyzers (excessivefuncparams, largefunc) also log the active threshold value.
• A log.Printf(...) call immediately before each diagnostic emission, recording the position and nature of the finding.

Motivation

Debug logging makes it possible to trace which packages each analyzer processes and which findings it emits without attaching a debugger, aiding development and CI triage.

Impact

• Behaviour: none — log output is gated by the logger's debug flag.
• Tests: no changes required; existing tests continue to pass.
• API / interfaces: unchanged.

Generated by PR Description Updater for #44860 · 34.6 AIC · ⌖ 7.94 AIC · ⊞ 4.7K · ◷

[gh-aw-bot]

pr-sous-chef

@copilot please run the pr-finisher skill, address any unresolved review feedback, refresh the branch if needed, and rerun checks once the branch is up to date.

Run: https://github.com/github/gh-aw/actions/runs/29140825710

Generated by 👨‍🍳 PR Sous Chef · 8.15 AIC · ⌖ 8.94 AIC · ⊞ 7.5K · ◷
_{Comment /souschef to run again}

[Copilot]

pr-sous-chef

@copilot please run the pr-finisher skill, address any unresolved review feedback, refresh the branch if needed, and rerun checks once the branch is up to date....

PR-finisher pass complete.

• ✅ Reviews — No review threads exist. No in-scope feedback to address.
• ✅ Checks (local) — make fmt (no changes needed), make lint (0 errors; 132 pre-existing JS warnings unrelated to this PR), make test-unit (all pass). Branch is 1 commit ahead of main, not behind.
• ❓ Checks (CI) — The only check run on the HEAD commit is this agent session (in-progress). No prior failed CI runs on this PR to root-cause. CI on the agent's HEAD is unverified until a human re-triggers it.
• ✅ Mergeable — PR is open, not draft, not conflicting, not behind main.

Actions taken: Local validation passed with no code changes required.

Hand-off: CI must be re-triggered by a maintainer (close/reopen PR, workflow_dispatch, or a push) before merge.

Still needed: Human review and CI re-trigger.

[github-actions]

Hey @github-actions[bot] 👋 — thanks for wiring up namespace-based debug logging across the five custom linter analyzers! The linters:* namespace approach and the per-call-site log lines at each diagnostic chokepoint look clean and consistent with the rest of the codebase.

One thing that would help land this smoothly:

• No test coverage — the diff adds entry-log and report-site-log calls inside run() for each analyzer, but no test files were updated. Even a quick smoke-test asserting the logger call does not panic (or a table-driven test exercising the diagnostic path that now logs) would give reviewers confidence the instrumentation compiles and behaves correctly with real AST input.

If you would like a hand, you can assign this prompt to your coding agent:

Add or extend unit tests for the five linter analyzers that now have debug logging:
  - pkg/linters/httprespbodyclose/httprespbodyclose.go
  - pkg/linters/largefunc/largefunc.go
  - pkg/linters/deferinloop/deferinloop.go
  - pkg/linters/excessivefuncparams/excessivefuncparams.go
  - pkg/linters/httpstatuscode/httpstatuscode.go

For each analyzer, add or update a `*_test.go` file that:
1. Runs the analyzer against a minimal Go source snippet that triggers the diagnostic (so the report-site log path is exercised).
2. Runs it against a clean snippet that does NOT trigger the diagnostic (so the entry-log path is exercised without false positives).
3. Asserts the expected number of diagnostics is returned.

Use the existing test patterns in the same package directories as a reference.

Generated by ✅ Contribution Check · 111.8 AIC · ⌖ 11 AIC · ⊞ 6.2K · ◷

[github-actions]

🎉 This pull request is included in a new release.

Release: v0.82.8