[BUG] False positive in defer including check for named error return

[stefanvanburen]

Describe the bug
False positive with defer including check for named error return.

To Reproduce

func _(ctx context.Context) (retErr error) {
	ctx, span := otel.Tracer("foo").Start(ctx, "bar")
    defer func() {
		if retErr != nil {
			span.SetStatus(codes.Error, retErr.Error())
        	span.RecordError(retErr)
		}
		span.End() // always ended
	}()

    if err := subTask(ctx); err != nil {
        return err
    }
}

Expected behavior
No spancheck lint on the ended span, since it's always ended.

Additional context
This is a somewhat common pattern that I've seen used to always capture the error from any returned error in a function, that seems to trip up spancheck - it should be able to tell that span.End() is unconditionally ended, despite not being the first statement in the defer?

[jjti]

I feared the day this bug report would arrive... I've hit this myself, honestly, and also like that approach of using named errors to set the status and error on the span. I gave a fix 30m a bit ago, but haven't properly fixed it. I have a long flight coming up that might be an ideal time...

[chancez]

Just wanted to note that this seems to been coming up if there's any conditionals in the defer, just in case that helps.

[jjti]

@stefanvanburen @chancez I think this is fixed now. Added a test case here well showing it not reporting missing calls: v0.6.3...v0.6.4

It'll take a bit before it's merged and released in golangci-lint (assuming that's how you're using the linter). Please report here and re-open this issue if it persists after picking up this latest version tho, v0.6.4