Upgraded specs2 to 5.0.0-RC-07 for Scala3

[etorreborre]

and reformatted the fragments a bit to look better when using Scala 3.

This PR prepares discipline-specs2 for the upcoming specs2-5.0.0 release.

[vasilmkd]

This turned out to be easier than expected?

[etorreborre]

Well, unless I missed something :-)

[vasilmkd]

This looks good to me, but I will wait for another review from @djspiewak and @armanbilge.

[vasilmkd]

The final thing to consider is whether to release stable versions that depend on release candidates.

[etorreborre]

I propose to wait a bit until I publish the final specs2-5.0.0. I need to address the cats-effect-testing library first.

[djspiewak]

This makes me really nervous because it makes it very hard for users to easily cross-build between Scala 2 and Scala 3.

[armanbilge]

@rossabaker suggested in #192 (comment) that the next version of discipline-specs2 is Scala 3 only.

[djspiewak]

That's probably reasonable. It'll be more of a problem for cats-effect-testing though

[armanbilge]

The final thing to consider is whether to release stable versions that depend on release candidates.

@vasilmkd would you mind publishing a snapshot so I can test this downstream? :)

[vasilmkd]

@armanbilge

Snapshot release will be available soon.

"io.vasilev" %%% "discipline-specs2" % "1.2-7-e3ce260"

[armanbilge]

Awesome, thanks! Trying now.

[armanbilge]

Cool, works in https://github.com/armanbilge/cheshire/runs/3546471023. Trying another one of my projects next.

[armanbilge]

Update, also working in https://github.com/armanbilge/schrodinger/runs/3547259110. That's more interesting maybe because it tests monad transformers against CE3 laws.

@etorreborre I just realized the discipline output is sometimes missing newlines, e.g. https://github.com/armanbilge/cheshire/runs/3546471023#step:6:70

[etorreborre]

@armanbilge thanks I thought I had tested that but I must have missed the mutable spec case. I will fix it.

[etorreborre]

Actually I'm not sure if there's a meaningful fix in discipline-specs2. The easiest thing, if you are using a mutable spec is to intersperse some brs in between the checkAll calls:

class MutableDisciplineSpec extends Specification with Discipline {
  checkAll("Int1", RingLaws.ring); nl
  checkAll("Int2", RingLaws.ring); nl
  checkAll("Int3", RingLaws.ring)

  def nl = { br; br }
}

I tried to write a display function doing this interspersing but given the amount of side effects in a mutable spec this is close to impossible!

The simplest thing is actually to use a non-mutable spec:

class DisciplineSpec extends Specification with Discipline {
  def is =
      checkAll("Int1", RingLaws.ring) ^
      checkAll("Int2", RingLaws.ring) ^
      checkAll("Int3", RingLaws.ring)
}

[armanbilge]

@etorreborre thanks for looking into this so quickly. Apologies if I'm missing something, but can't the nl just be baked into the checkAll method?

[etorreborre]

If you do it then you have an extra nl at the end of the spec even if there's only checkAll being called. If that's ok with you, you can define:

def check(name, prop) = { checkAll(name, prop); br; br }

Having some sort of wysiwig display in specs2 is quite hard, either when side-effects are involved with a mutable spec or with a s2""" ... """ string in an immutable spec (to respect newlines and whitespace). I tried to improve the situation in specs2-5.x but there are definitely some corner cases that will pop-up.

[armanbilge]

If you do it then you have an extra nl at the end of the spec even if there's only checkAll being called.

IMO we should make that change in this PR. An extra nl is preferable to I suspect nearly every downstream having to account for this one way or another. Thoughts @djspiewak @vasilmkd?

[etorreborre]

I prefer to be able to control exactly how things are displayed but the user is king :-).