[BUG] False Positive for the MatchError matcher used to assert a non error type in Eventually cases

[maboehm]

Describe the bug
Using a function inside of Eventually() is not correctly handled by the linter.

This is accepted:

Eventually(func() error {
	return fmt.Errorf("an error")
}).Should(MatchError(ContainSubstring("error")))

But replacing the function declaration with a function that returns the function returns an error (see below), but is one way described even in the docs: https://onsi.github.io/gomega/#category-2-making-codeeventuallycode-assertions-on-functions and is equivalent to the in-line example

To Reproduce

package main_test

import (
	"fmt"
	"math/rand"
	"testing"

	. "github.com/onsi/ginkgo/v2"
	. "github.com/onsi/gomega"
)

func TestE2E(t *testing.T) {
	RegisterFailHandler(Fail)
	RunSpecs(t, "demo")
}


func bar() func() error {
	return func() error {
		return fmt.Errorf("an error")
	}
}

var _ = Describe("the MatchError matcher used to assert a non error type", func() {
	It("should work", func() {
		Eventually(bar()).Should(MatchError(ContainSubstring("error")))
	})
})

Results in

main_test.go:28:3: ginkgo-linter: the MatchError matcher used to assert a non error type (bar())

Expected behavior
No linting error

**E
Environment:

• OS: macos
• Version latest (0.18.1)
• go: 1.22.9

Additional context
We first observed this when bumping golangci-lint, which bumped this linter from 0.16.0 to 0.18.0

Might be related to #173 since we started seeing it at the same time and both have to do with error checking.

[nunnatsa]

Thanks @maboehm - I'll take a look. I think this and #173 are two different bugs.

[nunnatsa]

Just released v0.18.2 with a fix to this bug.