fix: adjust tests for 3.2.0-NIGHTLY #3687
Conversation
dos65
force-pushed
the
scala_3.2.0-nightly
branch
from
1807223 to
7cc949d
Compare
| def undoBacktick(label: String): String = | ||
| label.stripPrefix("`").stripSuffix("`") |
There was a problem hiding this comment.
I'm assuming these are due to my changes in scala/scala3#14594. Is this how we want to handle this though? In these cases aren't we stripping them here and then adding them back later? Would it be better to instead check when we are about to add them and if they exist already, then don't add them?
There was a problem hiding this comment.
@ckipp01 I agree that it isn't perfect but they anyway should be removed from completion label
There was a problem hiding this comment.
Except for @ckipp01 's comment, it's LGTM from my side (I left one comment).
| } | ||
| .getOrElse((None, None)) | ||
| val date = parts.lift(5).map(_.toInt) | ||
| Version(major, minor, patch, rc, milestone, date) |
There was a problem hiding this comment.
| @@ -81,7 +81,7 @@ class HoverScala3TypeSuite extends BaseHoverSuite { | |||
| |""".stripMargin, | |||
| "", | |||
| compat = Map( | |||
| "3.1.3-RC1" -> | |||
| ">=3.1.3-RC1-bin-20220301-fae7c09-NIGHTLY" -> | |||
There was a problem hiding this comment.
Can we say >3.1.3-RC1 here? (this is not a strong opinion. If you prefer this way, go ahead 👍 )
- If we write
>3.1.3-RC1, the nightly releases of3.1.3-RC1before20220301will fail, but do we test against older Scala3 nightly release? - I feel it's too specific
- If we can write
>3.1.3-RC1, we can omitnightlyDatefield fromVersioncase class, and keep it simple :)
There was a problem hiding this comment.
@tanishiking Initially I wanted to use just > but then realized that the actual usage of this might be gte only. Some change happens in specific version so you add a new compat case that should be used from this version and next ones.
I agree that >= is more verbose than > but I think at least it's more clear.
If we write >3.1.3-RC1, the nightly releases of 3.1.3-RC1 before 20220301 will fail, but do we test against older Scala3 nightly release?
We have a ci workflow that tests and backpublishes support of new scala3-nightly versions for the latest Metals version.
Being too specific with versions will help to stabilize this workflow as currently it often fails.
There was a problem hiding this comment.
Thank you for the detailed explanation!
We have a ci workflow that tests and backpublishes support of new scala3-nightly versions for the latest Metals version.
Being too specific with versions will help to stabilize this workflow as currently it often fails.
I'm convinced that being specific with versions would be better. Now, it's LGTM from my part.
| .map { case (v, a) => | ||
| (SemVer.Version.fromString(v.stripPrefix(">=")), a) | ||
| } | ||
| .filter({ case (v, _) => parsed >= v }) |
There was a problem hiding this comment.
| .filter({ case (v, _) => parsed >= v }) | |
| .filter { case (v, _) => parsed >= v } |
There was a problem hiding this comment.
thx for suggestions! applied all of them
dos65
force-pushed
the
scala_3.2.0-nightly
branch
from
eacab93 to
dca18d4
Compare
Also, exnteded the `compat` inn tests cases. Now it's possible to specify matching version not only as starts with but as greater or equal. For example: ``` check( "input ... ", "default expected ...", compat = Map( ">=3.1.0" -> "expected for version gte than 3.1.0", "3" -> "any otherversion that starts from 3" ) ) ``` Co-authored-by: Kamil Podsiadło <[email protected]>
dos65
force-pushed
the
scala_3.2.0-nightly
branch
from
dca18d4 to
1cdaa25
Compare
Also, exnteded the `compat` inn tests cases. Now it's possible to specify matching version not only as starts with but as greater or equal. For example: ``` check( "input ... ", "default expected ...", compat = Map( ">=3.1.0" -> "expected for version gte than 3.1.0", "3" -> "any otherversion that starts from 3" ) ) ``` Co-authored-by: Kamil Podsiadło <[email protected]>
Also, extended the
compatin tests cases.Now it's possible to specify matching version not only as starts with
but as greater or equal.
For example: