It seems like the `Result` assertions don't all wo...

# strikt

[dave08]

It seems like the Result assertions don't all work anymore... they complain that Result<T> can't be cast to T... maybe the fact that my T is nullable is the cause?

[christophsturm]

i had that problem with 1.4.30 rc but then it disappeared

[dave08]

I'm on 1.4.32...

[christophsturm]

are you seeing it in your local tests or in the strikt test suite? maybe it happens with the IR backend?

[christophsturm]

also if you can, try if it goes away with 1.5

[dave08]

With IR in my local tests. I'm waiting until all the 1.5 tooling comes out, and then I guess I could try, thanks!

[robfletcher]

I have workarounds for it in a couple places, but yes I think this is a Kotlin bug

[dave08]

This is one of the places that there's a workaround, but it still failed... does 1.5 solve this?

[robfletcher]

e.g. https://github.com/robfletcher/strikt/blob/main/strikt-core/src/main/kotlin/strikt/assertions/Result.kt#L27-L36

[robfletcher]

I haven’t tried building with 1.5 yet

[robfletcher]

is it out?

[robfletcher]

(just woke up!)

[dave08]

Not yet... well, it's on maven, just the tooling is not here and the official blog post didn't announce it.

[dave08]

1.5.0-RC is out, but I can't try it right now.

[dave08]

Meanwhile, I had to do something VERY messy:

expect {
                that(result.isSuccess).isTrue()
                that(result2.exceptionOrNull()).isNotNull().isA<UniqueFieldConstraintViolation>().and {
                    get(UniqueFieldConstraintViolation::fieldName).isEqualTo("field1")
                }
                that(result3.exceptionOrNull()).isNotNull().isA<UniqueFieldConstraintViolation>().and {
                    get(UniqueFieldConstraintViolation::fieldName).isEqualTo("field2")
                }
            }

[robfletcher]

ugh

[dave08]

Yup, deciphering such a test failing 🤒🤕...

[dave08]

Funny that the test seems to throw at the last getOrThrow() here:

fun <R> Assertion.Builder<Result<R>>.isSuccess(): Assertion.Builder<R> =
  assert("is success") {
    when {
      it.isSuccess -> pass()
      else -> fail(
        description = "threw %s",
        actual = it.exceptionOrNull(),
        cause = it.exceptionOrNull()
      )
    }
  }
    .get("value") {
      // WORKAROUND - Handle inline class bug. (This will also work when this bug is fixed)
      val value = getOrThrow()
      if (value is Result<*>)
        @Suppress("UNCHECKED_CAST")
        return@get value.getOrThrow() as R
      // WORKAROUND - END

      getOrThrow()
    }

[dave08]

As if it skips the workaround or something...

[dave08]

No, it seems like debugging this is VERY FUNNY, I can't even get it to stop on a break point in that function... I think it is trying that cast, but not succeeding...

[robfletcher]

I suspect that’s something to do with the way inline classes get compiled

[dave08]

I even tried tailing the call inside the runCatching with !! to make sure that nullability wasn't the issue --- no go, still don't work.

[dave08]

Maybe it's the IR compiler

[dave08]

Because I remember it used to work for other projects.

[robfletcher]

oh yeah, I have not been able to enable the IR compiler in Strikt yet because of the strikt-gradle module

[robfletcher]

huh, and the error when I do that is java.lang.ClassCastException: class kotlin.Result$Failure cannot be cast to class kotlin.Result so it may well be related

[dave08]

Oh... well in 1.5 you might not have a choice, IR is supposed to be the default... I hope upgrading won't cause other problems with all our test suites 😧. I'd guess that the Gradle Kotlin DSL's kotlin version is always going to be behind the current releases, is that the reason?

[robfletcher]

Yes, I believe so. I’ve been trying to figure out if there’s a way to use gradleTestKit but exclude the bundled Kotlin but I don’t think there is

[robfletcher]

and I can’t even just turn of IR in strikt-gradle because the problem is the IR-compiled code from strikt-core

[dave08]

If it's just the stdlib that's the problem, there's an option to not have that included automatically. But why not just separate strikt-gradle from the rest and let it depend on an older version of core?

[robfletcher]

That is probably the best approach, yes

[robfletcher]

although the issue then would be that if you were using strikt-gradle alongside any other modules the version alignment would be pretty confusing

[robfletcher]

it may just be a facet of the specific test in strikt-gradle

[robfletcher]

but it’s certainly related to this whole weird issue around Result.value seemingly returning itself in some contexts

[christophsturm]

i thought all of that would be fixed by 1.5 final?

[robfletcher]

hopefully

[robfletcher]

but that also depends on a version of Gradle that bundles Kotlin 1.5 in its testKit which will lag behind a bit

[robfletcher]

unless 1.5 fixes backward compatible cross-compilation I guess

[robfletcher]

oh boy, building Strikt with Kotlin 1.5.0 makes the problem with Result even worse