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

fix(gnovm): follow up works on loop scope(#2429) #2440

Merged

Conversation

ltzmaxwell
Copy link
Contributor

@ltzmaxwell ltzmaxwell commented Jun 25, 2024

        for i, _ := range s {
		s1 = append(s1, &i)
	}

this is not supported:

        for i := 0; i < 3; i++ {
		fs = append(fs, func() { println(i) })
	}

@github-actions github-actions bot added the 📦 🤖 gnovm Issues or PRs gnovm related label Jun 25, 2024
Copy link

codecov bot commented Jun 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.79%. Comparing base (e3ad91f) to head (d24a3d5).

Additional details and impacted files
@@                 Coverage Diff                 @@
##           dev/jae/loopescape    #2440   +/-   ##
===================================================
  Coverage               54.79%   54.79%           
===================================================
  Files                     583      583           
  Lines                   78965    78929   -36     
===================================================
- Hits                    43269    43250   -19     
+ Misses                  32464    32450   -14     
+ Partials                 3232     3229    -3     
Flag Coverage Δ
contribs/gnodev 23.81% <ø> (ø)
contribs/gnofaucet 14.46% <ø> (ø)
contribs/gnokeykc 0.00% <ø> (ø)
contribs/gnomd 0.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ltzmaxwell ltzmaxwell force-pushed the dev/maxwell/dev/jae/loopscope branch from 241ecc9 to c6411d6 Compare July 1, 2024 09:47
@ltzmaxwell ltzmaxwell changed the base branch from init_static to dev/jae/loopescape July 1, 2024 12:53
@ltzmaxwell ltzmaxwell requested a review from a team as a code owner July 19, 2024 14:47
@github-actions github-actions bot added the 🧾 package/realm Tag used for new Realms or Packages. label Jul 19, 2024
@ltzmaxwell ltzmaxwell requested a review from gfanton as a code owner July 20, 2024 02:13
@github-actions github-actions bot added the 📦 ⛰️ gno.land Issues or PRs gno.land package related label Jul 20, 2024
Comment on lines -299 to +311
for _, rte := range n.Type.Results {
if rte.Name != "" {
n.Predefine(false, rte.Name)
for i, rte := range n.Type.Results {
if rte.Name == "" {
rn := fmt.Sprintf(".res_%d", i)
rte.Name = Name(rn)
}
n.Predefine(false, rte.Name)
Copy link
Contributor Author

@ltzmaxwell ltzmaxwell Jul 20, 2024

Choose a reason for hiding this comment

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

define hidden .res_x in initStaticBlocks to preserve the original init order: [param_0, param_1...param_n, res_0, res_1...res_n, var_0, var_1...var_n] . the order is changed by he initStaticBlocks logic to be [param_0, param_1...param_n , var_0, var_1...var_n, res_0, res_1...res_n].

This order will impact defer logic.

Another workaround is to modify the runtime returnToBlock and returnFromBlock logic.

// },
// "FileName": "main.gno",
// "IsMethod": false,
// "Name": "init.0",
// "Name": "init.1",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

is this introduced by the initStaticBlocks?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes.

Comment on lines +240 to 259
// "@type": "/gno.PointerType",
// "Elt": {
// "@type": "/gno.RefType",
// "ID": "gno.land/p/demo/avl.Node"
// }
// },
// "V": {
// "@type": "/gno.PointerValue",
// "Base": {
// "@type": "/gno.RefValue",
// "Hash": "e925bb6bf884ece9620dd27f831dc510b5bc0e55",
// "ObjectID": "a8ada09dee16d791fd406d629fe29bb0ed084a30:6"
// },
// "Index": "0",
// "TV": null
// }
// },
// {
// "T": {
// "@type": "/gno.FuncType",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

package var is inited firstly in initStaticBlocks, the the order changes.

@@ -4311,7 +4366,7 @@ func setNodeLocations(pkgPath string, fileName string, n Node) {
// XXX check node lines, uniqueness of locations,
// and also check location pkgpath and filename.
func checkNodeLinesLocations(pkgPath string, fileName string, n Node) {
// XXX
// TODO: XXX
Copy link
Contributor Author

Choose a reason for hiding this comment

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

should be in another PR.

Comment on lines -2678 to 2729
n.SetAttribute(ATTR_LOOP_DEFINES, lus)
// XXX implement delete.
// n.DelAttribute(ATTR_LOOP_USES)
// no need anymore
n.DelAttribute(ATTR_LOOP_USES)
n.DelAttribute(ATTR_LOOP_DEFINES)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

no need anymore?

Comment on lines -250 to 254
last.Predefine(false, n.Key.(*NameExpr).Name)
nx := n.Key.(*NameExpr)
if nx.Name != blankIdentifier {
nx.Type = NameExprTypeDefine
last.Predefine(false, nx.Name)
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

maybe we should not support loopvar with range either, to make it consistent with for loop.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes. but TypeDefine is correct here as it is a define.

@@ -2549,28 +2569,43 @@ func addHeapCapture(dbn BlockNode, fle *FuncLitExpr, name Name) uint16 {
ne := NameExpr{
Path: vp,
Name: name,
Type: NameExprTypeHeapClosure,
Type: NameExprTypeHeapClosure, // XXX, this is actually not used, remove?
Copy link
Contributor

Choose a reason for hiding this comment

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

right it's not actually used, but let's leave it because it is a special kind of use of a name, to copy it to func value captures. It just means it was captured by a closure, for now.


// Copy *FuncValue.Captures into block
// NOTE: addHeapCapture in preprocess ensures order.
// XXX, actually copy
Copy link
Contributor

@jaekwon jaekwon Jul 25, 2024

Choose a reason for hiding this comment

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

I think we can remove the XXX right?

@jaekwon
Copy link
Contributor

jaekwon commented Jul 25, 2024

Brilliant.

@jaekwon jaekwon merged commit c9eeed2 into gnolang:dev/jae/loopescape Jul 25, 2024
51 of 52 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📦 ⛰️ gno.land Issues or PRs gno.land package related 📦 🤖 gnovm Issues or PRs gnovm related 🧾 package/realm Tag used for new Realms or Packages.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants