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

[6.0] Lazy default for Option.getOrElse and Coll.getOrElse #1008

Merged
merged 10 commits into from
Oct 21, 2024
Merged

Conversation

kushti
Copy link
Member

@kushti kushti commented Jun 11, 2024

In this PR , lazy default evaluation for Option.getOrElse and Coll.getOrElse is implemented

@kushti kushti changed the base branch from develop to v6.0.0 June 11, 2024 14:15
@kushti kushti self-assigned this Jun 11, 2024
@kushti kushti added this to the v6.0 milestone Jun 11, 2024
@kushti kushti changed the title Lazy default for Option.getOrElse and Coll.getOrElse [6.0] Lazy default for Option.getOrElse and Coll.getOrElse Jun 13, 2024
@kushti kushti requested a review from aslesarenko July 30, 2024 16:31
ValUse(1, SPair(SCollectionType(SInt), SPair(SInt, SInt))),
2.toByte

if(!VersionContext.current.isV6SoftForkActivated) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protocol change like this can be tested using changeFeature (see other tests) in combination with newVersionedResults (also see code). In this case both old and new behaviour will be tested.

In principle this test case can be moved to LSV6.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changedFeature is not enough here, you need for versioned verifyCases, as in 6.0 costing trace would be different in some cases due to difference in default evaluation (at the same time, it wouldnt provide higher cost, so the change is secure costing-wise).

Seems like *Feature machinery is overly complex, but still not enough to describe protocol changes, thus I would recommend to decide what it is actually testing (or should test), and then follow simpler approaches

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see other examples where changedFeature is used, there are test cases where cost trace depend on the version and you can pass different traces to the constructor of Expected.
The perceived complexity is due to learning curve.

Copy link
Member Author

@kushti kushti Aug 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changedFeature is tied to V4/V5 switch, see checkExpected in ChangedFeature / checkVerify functions in SigmaDslTesting. So it cant be used in V6 testing without modifications it seems. So it is definitely not about learning curve, changedFeature is just not ready for V6

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aslesarenko see #1024 for example

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

existingFeature({ (x: Option[Long]) => x.getOrElse(1L) },
"{ (x: Option[Long]) => x.getOrElse(1L) }",
FuncValue(Vector((1, SOption(SLong))), OptionGetOrElse(ValUse(1, SOption(SLong)), LongConstant(1L)))))
if (!VersionContext.current.isV6SoftForkActivated) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, this if is not necessary when changeFeature + newVersionedResults is used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above


if (VersionContext.current.isV6SoftForkActivated) {
forAll { x: Option[Long] =>
Seq(getOrElse).map(_.checkEquality(x))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check equality is not enough, as it doesn't involve all interpreter components.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please specify what is needed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

verifyCases will exercise all the components.

@kushti
Copy link
Member Author

kushti commented Jul 31, 2024

@aslesarenko comments addressed, please make another pass

@kushti
Copy link
Member Author

kushti commented Aug 9, 2024

@aslesarenko after all I've found some V6 related modifications in #995 , tweaked them further and made verifyCases tests. Please make another pass

@kushti kushti requested a review from aslesarenko September 27, 2024 13:00
@kushti kushti merged commit c21ed63 into v6.0.0 Oct 21, 2024
4 checks passed
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.

2 participants