Add or fix contracts in Raise

[serras]

K2 checks callsInPlace contracts much more thoroughly, which led to the discovery of some missing (and even one incorrect) contract.

[github-actions]

Kover Report

File	Coverage [80.12%]
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/Ior.kt	90.10%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/Option.kt	93.24%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/Builders.kt	65.69%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/Fold.kt	97.92%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/Raise.kt	96.97%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/RaiseAccumulate.kt	64.80%

Total Project Coverage	54.72%

[nomisRev]

IIRC we removed the contracts from builders, and recover since it was resulting in false "unreachable".

[nomisRev]

I think we removed these on purpose, because fun raise(error: Error): Nothing will result in code unreachable after either { }. If I understood that is the desired behavior from the compiler POV, so I expect it to be unchanged in K2.

I think that goes for everything in Builders.kt. I'd need to check git history, I should've documented it in the PR.

[serras]

I've made them strict using AT_MOST_ONCE, which should not have the same problem (yet it enables further analysis by the compiler).

On prolem is that the semantics EXACTLY_ONCE are not clear: does it mean we call the function, or that the function finishes execution? Given that raise stops the execution, that means that EXACTLY_ONCE wouldn't be true for the second meaning. And given the warnings in K2, this is what the compiler understands too.

[nomisRev]

On prolem is that the semantics EXACTLY_ONCE are not clear: does it mean we call the function, or that the function finishes execution? Given that raise stops the execution, that means that EXACTLY_ONCE wouldn't be true for the second meaning. And given the warnings in K2, this is what the compiler understands too.

Afaik EXACTLY_ONCE is meant for function that are called in place, and finishes execution but finishes execution can also mean resulted in an exception. The difference lies in that raise is caught, so we don't return the result of EXACTLY_ONCE but instead we manipulate the result of EXACTLY_ONCE by recovering from the raise.

Similar for runCatching, it manipulates the result of the block lambda by capturing any results. So I think it cannot be considered as EXACTLY_ONCE.

I'm not entirely sure what EXACTLY_ONCE, or AT_MOST_ONCE but the issue I originally removed EXACTLY_ONCE for is not occurring with AT_MOST_ONCE.

[nomisRev]

Possible suffers from same issue as builders.

[serras]

@nomisRev do you think it's worth keeping this PR (without the EXACTLY_ONCEs) or should I close it?

[nomisRev]

I think it's definitely worth merging this PR! Thank you for looking into this @serras 🙌