Anonymous structs should not be checked for exhaustiveness

[navijation]

In my experience, the most common use case for an anonymous struct is in unit test case loops. These should not typically be exhaustive-enforced because many fields are omitted by default to improve the brevity of the test case, e.g. test writers do not always want to specify expectErr: false everywhere.

Exhaustruct's current behavior on anonymous structs will be prohibitive for many if not most company codebases, including all the ones I've worked on in the past.

For backwards compatibility, this behavior should be configured with a flag.

[xobotyi]

There is no need in separate flag, we already have exclusion list - so the only requied thing is to allow matching anonymous structures by <anonymous> alias

[ImprintNav]

Not introducing the flag is backwards incompatible in the sense that code that would fail the linter before will now start to pass. If that's not a concern then that's fine.

[xobotyi]

@ImprintNav how is that? #65 only adds ability to exclude\include anonymous tags, without changing overall behaviour. anonymous structures are linted as it was before the change.

[navijation]

@xobotyi What I meant was that code which would have failed at the time due to anonymous structs would start to succeed after #65. e.g. with the following config

i:
  - i.Included

This configuration before #65 would fail on a repo with non-exhaustive anonymous structs because the old implementation always barred anonymous structs, but in the new interpretation, this same config would not include anonymous struct literals. If a repo actually intended for this behavior, upgrading would lead to silent loss of analyzer coverage when new anonymous struct literals are added.

I agree this is sublte and unlikely, however.