Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP Revival of Munit 225 #1

Closed
wants to merge 12 commits into from
Closed

WIP Revival of Munit 225 #1

wants to merge 12 commits into from

Conversation

valencik
Copy link
Owner

@valencik valencik commented Apr 15, 2022

scalameta#225

Things to not forget:

  • investigate special casing for Array comparisons?
  • perhaps make an issue upstream about the weird dotty compileErrors issue

This PR is mostly a freshly rebased version of scalameta#225.

It is absolutely worth reviewing the discussion in the original PR. However, I've copy and pasted its description here:

Previously, MUnit had a subtyping constraint on assertEquals(a, b) so
that it would fail to compile if a was not a subtype of b. This was
a suboptimal solution because the compile error messages could become
cryptic in some cases. Additionally, this API didn't integrate with
other libaries like Cats that has its own cats.Eq[A,B] type-class.

Now, MUnit uses a new munit.Compare[A,B] type-class for comparing
values of different types. By default, MUnit provides a "universal"
instance that permits comparison between all types and uses the built-in
== method. Users can optionally enable "strict equality" by adding the
compiler option "-Xmacro-settings.munit.strictEquality" in Scala 2.
In Scala 3, we use the Eql[A, B] type-classes instead to determine
type equality (per http://dotty.epfl.ch/docs/reference/contextual/multiversal-equality.html)

Note: the first few commits are unrelated to this feature, I cleaned up
a few small quirks I noticed while working on this feature.

Fixes scalameta#189

Binary Incompatibility

This PR introduces a binary breaking changes to the following methods:

  • munit.Assertions.assertNotEquals
  • munit.Assertions.assertEquals
  • munit.FunSuite.assertNotEquals
  • munit.FunSuite.assertEquals

Rebasing notes:

The rebase got a little hairy. During it I ditched special casing for array comparisons, so 1503667 reintroduces it. Similarly, b28073f reintroduces the better string inequality error messages.

Olafur Pall Geirsson added 5 commits April 15, 2022 07:05
Previously, FailException had some custom nice-to-have features that
ComparisonFailException didn't have.
Previously, MUnit had a subtyping constraint on `assertEquals(a, b)` so
that it would fail to compile if `a` was not a subtype of `b`. This was
a suboptimal solution because the compile error messages could become
cryptic in some cases. Additionally, this API didn't integrate with
other libaries like Cats that has its own `cats.Eq[A,B]` type-class.

Now, MUnit uses a new `munit.Compare[A,B]` type-class for comparing
values of different types. By default, MUnit provides a "universal"
instance that permits comparison between all types and uses the built-in
`==` method. Users can optionally enable "strict equality" by adding the
compiler option `"-Xmacro-settings.munit.strictEquality"` in Scala 2.
In Scala 3, we use the `Eql[A, B]` type-classes instead to determine
type equality.
This is a fourth attempt at improving strict equality in MUnit
`assertEquals()` assertions.

* First attempt (current release version): require second argument to be
  a supertype of the first argument. This has the flaw that the compile
  error message is cryptic and that the ordering of the arguments affects
  compilation.
* Second attempt: use `Eql[A, B]` in Scala 3 and allow comparing any
  types in Scala 2. This has the flaw that it's a regression in some
  cases for Scala 2 users and that `Eql[A, B]` is not really usable
  in its current form, see related discussion
  https://contributors.scala-lang.org/t/should-multiversal-equality-provide-default-eql-instances/4574
* Third attempt: implement "strict equality" for Scala 2 with a macro
  and `Eql[T, T]` in Scala. This improves the situation for Scala 2,
  but would mean relying on a feature that we can't easily port to Scala 3.
* Fourth attempt (this commit): improve the first attempt (current
  release) by allowing `Compare[A, B]` as long
  as `A <:< B` OR `B <:< A`. This is possible thanks to an observation
  by Gabriele Petronella that it's possible to layer the implicits to
  avoid diverging implicit search.

The benefit of the fourth approach is that it works the same way for
Scala 3 and Scala 3. It's very nice that we can avoid macros as well.
@valencik valencik self-assigned this Apr 15, 2022
The Scala 3 (dotty) tests now use compareSubtypeWithSupertype instead
of compareSupertypeWithSubtype. Additionally, the "unrelated" test was
not seeing the context code above and so I've moved all the code into
compileErrors.
@valencik
Copy link
Owner Author

Closing in favour of scalameta#521

@valencik valencik closed this Apr 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong order of arguments for assertEquals
1 participant