add ErrorAsType and related functions

[mattjohnsonpint]

Summary

Adds Testify functions that mirror the new errors.AsType[E] in Go 1.26.

Changes

For Go 1.26+ consumers, adds the following:

assert.ErrorAsType[E error](t TestingT, err error, msgAndArgs ...any) (E, bool)
assert.ErrorAsTypef[E error](t TestingT, err error, msg string, args ...any) (E, bool)
assert.NotErrorAsType[E error](t TestingT, err error, msgAndArgs ...any) bool
assert.NotErrorAsTypef[E error](t TestingT, err error, msg string, args ...any) bool

require.ErrorAsType[E error](t TestingT, err error, msgAndArgs ...any) E
require.ErrorAsTypef[E error](t TestingT, err error, msg string, args ...any) E
require.NotErrorAsType[E error](t TestingT, err error, msgAndArgs ...any)
require.NotErrorAsTypef[E error](t TestingT, err error, msg string, args ...any)

Note that E is returned where appropriate, to allow the caller to follow with additional requirements without further casting.

Motivation

Instead of:

var syntaxErr *json.SyntaxError
require.ErrorAs(t, err, &syntaxErr)

With this change, and if I'm using Go 1.26.0 or later, I can now write:

require.ErrorAsType[*json.SyntaxError](t, err)

Other functions are similar in usage to their existing *ErrorAs* counterparts.

Related issues

Closes #1860

[ccoVeille]

This sounds reasonable. I didn't check by pulling the branch, but the first look seems OK .

I was afraid you might break old Go versions by using a recent feature, but you used gu:build tag 👍

My only concern now is to check if the new files you add are auto generated or not.

[ccoVeille]

I'm unsure what this could mean and what would be the problems if you are not adding this to the PR

[dolmen]

To introduce generic functions in assert and require the code generator has to be improved.

Introducing generic functions without codegen will be too heavy to maintain.

[dolmen]

This must be a separate PR.

[dolmen]

This is not the way we must take.

To introduce generics in Testify, someone has to do the job of porting the code generator to support generics.

[dolmen]

In Testify assert, functions are also exposed as methods of the Assertions type.

Go doesn't yet supports methods with type parameters. While this is coming (see golang/go#77273), we aren't there yet. We need changes in the codegen that will be ready to handle methods with type parameters once they are there.

[mattjohnsonpint]

Thanks for the feedback. I'm away for the weekend but will revisit this soon.

[fredbi]

Yes interesting. The assertion expression is definitely lighter.

[mattjohnsonpint]

Revised substantially for Go 1.27 in #1937

[fredbi]

@mattjohnsonpint an implementation of this feature already exists at my fork github.com/go-openapi/testify/v2 - it might provide you some extra inspiration, although it is essentially in the same spirit as your implementation. The fork is planned to support the generic "forward" methods in a few weeks (waiting for go1.27 to release).

Super happy that the code generator at stretchr/testify gets some uplifting! thanks.

Fred

[mattjohnsonpint]

@fredbi - yeah, that's what my #1937 PR does. Go 1.27 was released today BTW.