Deprecate/remove interfacer from supported linters

[dackroyd]

mvdan/interfacer@c200402

Deprecated: A tool that suggests interfaces is prone to bad suggestions, so its usefulness in real code is limited. This tool will remain available as a proof of concept, and for others to examine and learn from.

[jirfag]

Hi,

1. we can't do it before v2.0.0
2. I'm not sure we should do it because some users may find it useful.
3. but we can disable it from default set of linters

[andig]

I second this. Interfacer produces false positives, too.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pkuca]

Interfacer is used to create a fair comparison with gometalinter in the benchmarks - how should that be handled?

#1689 is a dupe

[ldez]

gometalinter is now archived so a fair comparison with a dead project seems impossible.
https://github.com/alecthomas/gometalinter#go-meta-linter

[pkuca]

Agreed - knowing that, I can take this unless @sayboras has stuff in progress I see it's queued up for v2, so nevermind.

[sayboras]

Feel free to take over this. Thanks 💯

[pkuca]

Is it worth leaving this open until v2 and the removal PR's start coming in? I'd probably just close it because the interfacer is deprecated properly now (thanks @SVilgelm )

[SVilgelm]

I think, it's better to create an issue and label it as v2 and we will re-open this PR later

[richardwilkes]

There should be a way to disable this warning for those of us that still want to use things like interfacer with golangci-lint. As it is, since the introduction of this, our tests now fail because of this (spurious to us) warning.

[ldez]

@richardwilkes as the linter is deprecated by the author itself, we recommend disabling this linter.

There is an internal hidden flag to hide this message but without any warranty to be stable in the future.

[richardwilkes]

Ah... what is that flag? Not 100% necessary, as I found I can filter the stderr easily enough... but I actually find both interfacer and maligned to be useful. And the option to use govet's fieldalignment is a non-starter, as it is just plain wrong in its analysis.

[ldez]

maligned has been also deprecated by the author itself: https://github.com/mdempsky/maligned

maligned has been replaced by fieldalignment linter in govet

"The repository of the linter has been archived by the owner. Use govet 'fieldalignment' instead."

https://golangci-lint.run/usage/configuration/

 govet:
    enable:
      - fieldalignment

or

 govet:
    enable-all: false

[ldez]

Those linters will be removed in the future, so it's time to disable it from your configuration 😉

[richardwilkes]

Understood... however, removing a linter that provides a valuable service (like maligned) when the replacement doesn't actually work correctly, is not good. It doesn't seem to understand the correct sizes of struct fields and issues warnings that are incorrect. Example -- for this struct:

type foo struct {
    a string
    b []string
    c string
}

govet will report "fieldalignment: struct with 48 pointer bytes could be 40 (govet)"

However, using unsafe.Sizeof() shows the struct is actually 56 bytes, with 16 bytes consumed for each string and 24 for the slice. With 8 byte alignment on my platform, there is nothing that can be improved. maligned works fine for this same case.

[ldez]

I suggest you open an issue here: https://github.com/golang/go/issues/new/choose

The issues related to golang.org/x/tools are globally handle quickly as it's not a part of the core.

[KnBrBz]

Understood... however, removing a linter that provides a valuable service (like maligned) when the replacement doesn't actually work correctly, is not good. It doesn't seem to understand the correct sizes of struct fields and issues warnings that are incorrect. Example -- for this struct:

type foo struct {
    a string
    b []string
    c string
}

govet will report "fieldalignment: struct with 48 pointer bytes could be 40 (govet)"

However, using unsafe.Sizeof() shows the struct is actually 56 bytes, with 16 bytes consumed for each string and 24 for the slice. With 8 byte alignment on my platform, there is nothing that can be improved. maligned works fine for this same case.

Here fieldalignment is a note:

Note that there are two different diagnostics reported. One checks struct size,
and the other reports "pointer bytes" used. Pointer bytes is how many bytes of the
object that the garbage collector has to potentially scan for pointers, for example:

struct { uint32; string }

have 16 pointer bytes because the garbage collector has to scan up through the string's
inner pointer.

struct { string; *uint32 }

has 24 pointer bytes because it has to scan further through the *uint32.

struct { string; uint32 }

has 8 because it can stop immediately after the string pointer.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ldez]

Related to the deprecation process #1987