Mocks generated for constraint interfaces/anys

[j-waters]

Description

Upon upgrading from v3.3.4 to v3.5.4, we found that mockery is now generating mocks for some categories of types that I don't think it should:

• type A constraints.Ordered
• type B any

I also realised that mockery was already generating mocks for:

• type C interface { constraints.Float | constraints.Integer }

Reproducer

Create types like the ones above and run mockery

Expected behavior

Mocks shouldn't be generated for those types

Mockery version

v3.5.4

Installation Mechanism

• [x] go get
• [ ] Pre-built release
• [ ] homebrew
• [ ] Other: [please describe]

Go version

v1.25

[LandonTClipp]

This is probably the change that caused this: https://github.com/vektra/mockery/pull/1074

Parsing happens in two steps:

1. Look for syntax that appears to be a type definition for a possible interface or an alias to an interface.
2. Further inspect the type information to ensure that this type definition or alias does in fact refer to an interface.

The first step is what was updated recently, so I'll have to look into why it's allowing type constraints to be generated. My hunch is that is slipped through because type constraints are interfaces, so we need to add an additional qualifier to check if the interface is a constraint or not.

[Alhanaqtah]

This is probably the change that caused this: #1074

Parsing happens in two steps:

1. Look for syntax that appears to be a type definition for a possible interface or an alias to an interface.

2. Further inspect the type information to ensure that this type definition or alias does in fact refer to an interface.

The first step is what was updated recently, so I'll have to look into why it's allowing type constraints to be generated. My hunch is that is slipped through because type constraints are interfaces, so we need to add an additional qualifier to check if the interface is a constraint or not.

Hi! I'm currently working on this issue. I've made mockery able to consider whether an interface is a constraint. I wanted to clarify whether it is necessary to make sure that empty interfaces are not generated?

P.S. Please take a look at this pool request, which mostly solves the problem with constraint interfaces)

[LandonTClipp]

@Alhanaqtah thank you for the PR, I will take a look soon. I don't think we need to exclude empty interfaces, although it would be strange to want mocks for it.