Fix #9642 Compare operations of ops classes in assertTrue #9798
Conversation
| case (None, _) => | ||
| val span = getSpan(tree) | ||
| '{ TestArrow.succeed($expr).span($span) } | ||
| case _ => throw new Error("NO") |
There was a problem hiding this comment.
| case _ => throw new Error("NO") | |
| case _ => throw new IllegalArgumentException("Unsupported operation in 'assertTrue'\nPlease open an issue: https://github.com/zio/zio/issues/new") |
There was a problem hiding this comment.
I just thought maybe it should not be the problem of the end user if they include some strange compare expressions? We can't really predict what kind of expressions are possible here, however, they might appear in the future, maybe we should simply allow all of them. And moreover it should not be the problem of this codebase to handle exception cases, such as what I wrote: case (None, _) => ... only for the specific conversion direction and only when a bug has been submitted.
What I mean is that instead of throwing this strange exception, which appears only in expressions with compare operations, simply do the '{ TestArrow.succeed($expr).span($span) } like it is already done when the tree does not match any other patterns (lines 383-385 in the original code)?
There was a problem hiding this comment.
I am not sure I 100% understand, but I think you're saying the case you added should be a 'catchall'? Even if that's the case, I think it's better to leave a way to report bugs/issues and we can choose to fix/not fix them. ERROR("NO") is not descriptive.
There was a problem hiding this comment.
Since this is used in a macro, why not throw a proper compiler error with the error message suggested by @hearnadam?
| case _ => throw new Error("NO") | |
| case _ => scala.compiletime.error("Unsupported operation in 'assertTrue'\nPlease open an issue: https://github.com/zio/zio/issues/new") |
Or is that not possible?
There was a problem hiding this comment.
@kyri-petrou, yes it's possible, I have changed the error message to the one suggested by @hearnadam and used the compiler error like you suggested. The only thing I changed is moved this error expression to a separate def, since it is reused three times in places where "NO" exception was before.
Fix #9642
This PR fixes an issue in
assertTruemacro that did not allow using compare operation (>, >=, <, <=) inside of it when they were extension methods.The problem was that when the macro matched a tree with such an operation it always "tried" to summon an instance of
Ordering[l]wherelis the type of lhs. However, sometimes when having an ops class and implicit conversions to its instance does not mean that there is anOrderinginstance for the type (actually I believe it's always the case). In other words, it is just an extension method that's why the macro would never work in Scala 3.I have only changed the logic when
implicitConversionDirectionvalue isSome(false)(direction from the type on the rigth to the one on left) since all the comparison operators are left associative.