Behaviour Change of whenever in combination with "typeless" any() since 6.2.0

[goafabric]

Before version 6.2.0 this mock statement worked perfectly fine

whenever(personRepository.saveAndFlush(any())).thenReturn(person)

....

Now since 6.2.0 we get
Cannot infer type for type parameter 'T'. Specify it explicitly.

which can be fixed by setting the type excplitly

whenever(personRepository.saveAndFlush(any())).thenReturn(person)

...

Is this change intentionally ? Because at first sight i didn't see in the release notes.
And it breaks a lot of tests on our end.

[TimvdLippe]

FYI @m-koops

[m-koops]

Hi @goafabric, thank you for raising this issue. The change you observe is not intentional, rather a side-effect of introducing improved support for suspend functions.

Given the signature of whenever(personRepository.saveAndFlush(any())).thenReturn(person), I suppose this code is about mocking a Spring Data repository, right?
In Spring Data Jpa class JpaRepository defines saveAndFlush() as (translated into Kotlin):
fun <S: T> saveAndFlush(entity: S): S

Taking that definition as a starting point, I was able to reproduce the issue with this fragment of code:

    private class Person
    
    private interface DummyJpaRepository<T> {
        fun <S: T> saveAndFlush(entity: S): S
    }

    private interface PersonRepository: DummyJpaRepository<Person>
    
    @Test
    fun test() {
        val person: Person = mock()
        val personRepository: PersonRepository = mock()

        whenever(personRepository.saveAndFlush(any()) )
            .thenReturn(person)
    }

In Mockito-Kotlin 6.1.0 only the function fun <T> whenever(methodCall: T): OngoingStubbing<T> was defined. In version 6.2.0 that function still remains, but an overload function fun <T> whenever(methodCall: suspend () -> T): OngoingStubbing<T> was added to support whenever for suspend functions.

The 'cannot infer type' problem is caused by the compiler prefering the new suspend function overload over the old one, although the actual call is not about a suspend function.
When I remove the new overload, then the compiler resolves the old definition of whenever and no type inference problem occurs. But with the new overload available, the compiler selects that overload and reports the error.

Right now, I do not have a clear solution yet. I have no idea if anything can be done to help the compiler select the other overload. I found out that the Kotlin compiler team is working on improved overload resolution recently (see https://kotlinlang.org/docs/whatsnew2220.html#improved-overload-resolution-for-lambdas-with-suspend-function-types) but testing the above test with latest Kotlin (2.3.10) still fails with 'cannot infer type' problem.

[m-koops]

PR #585 reproduces the problem in new generics tests added to the test suite.

[goafabric]

@m-koops
thanks for getting back .. its not about macking the entire repository, just the return value / entity

I was able to workaround in our code by setting the concrete value like any()
which is anyways cleaner as the generic any.
So as there is a viable workaround, the priority is not that high, just wanted to not the behavioural change, as on our end multiple projects need to be adjusted

[m-koops]

I have reported the compiler error to Jetbrains, see: KT-84171 Overload resolution problem