-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support allowlisting via a comment rather than global config #37
Comments
@xobotyi Do you have any thoughts on the merits of this suggestion? It is likely to cause a performance hit due to multi-pass, but that can be gated by a flag. The added cost is likely worth it for many organizations compared to the cache invalidation cost of editing the golangci-lint config upon every new struct to be allowlisted. |
It is somehow achievable without true multipass - i've been planning to review this\next week when ill have some free time. |
Having to specify every covered struct in a global configuration file isn't ideal for reasons such as build incrementalism. I suggest also supporting an approach similar to the one used in nishanths/exhaustive, except at the struct level.
Unlike in that other analyzer, it probably makes sense to always enforce presence at every site of struct initialization by default if the struct is configured to require parameters. This is consistent with e.g. how most languages deal with named, required parameters to function calls.
A global configuration flag
-explicit-exhaustive-struct
with default valuefalse
would be required to maintain backwards compatibility (in the sense of ensuring previously failed builds continue to fail).The text was updated successfully, but these errors were encountered: