Add handled response directive - #81
Conversation
|
I also tried an automatic interprocedural analysis based on analysis.Fact and buildssa which are known to add significant analysis overhead. On a synthetic package with 1000 response helpers and 1000 call sites the median runtime increased from 1.15 sec to 2.97 sec and RSS increased from 31 MB to 851 MB. Because this adds a large default cost, I chose an explicit directive instead. It showed no measurable overhead compared with the baseline. |
|
@timakin, could you take a look when you have a chance? |
|
@timakin Thanks for the quick merge! I would also like to update bodyclose in golangci-lint. Their PR template says that linter update PRs should come from the original linter author. I can prepare the bump PR myself. Would you be okay with that and could you confirm your support or point me to the right maintainer/reviewer? Another option is that I can help finish #73 and add an automated SemVer release after every merged pull request. Since golangci-lint uses dependabot for updates, it could then pick up new bodyclose versions automatically. Would this second option be better for the project? |
|
Thanks — I’d really appreciate the help. Let’s prioritize the golangci-lint bump so users can get Please go ahead and prepare the update and link back to this comment. I confirm, as the original author/maintainer of bodyclose, that I support the bump. If golangci-lint requires the PR itself to be opened by me, feel free to prepare the patch/branch and I’ll submit it with you credited, or we can coordinate with their maintainers from there. Release automation would also be valuable, but I’d prefer to handle it separately from this bump. #73 needs to be rebased and updated first, and I think CI modernization and release automation should be separate changes rather than automatically publishing a release after every merge. Once the golangci-lint update is moving, I’d be happy to work with you on that follow-up as well. |
Add
//bodyclose:handledto mark functions that fully handle returned response bodies, preventing false positives at statically resolved call sites, including across packages.Related to #71 and #76.