fix: global var dependencies #2077
Conversation
petar-dambovaliev
requested review from
jaekwon,
moul,
piux2,
deelawn,
thehowl and
mvertes
as code owners
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
petar-dambovaliev
requested review from
a team,
gfanton and
leohhhn
as code owners
github-actions
bot
added
🧾 package/realm
petar-dambovaliev
force-pushed
the
vardeps
branch
from
c7365aa to
813b7e1
Compare
There was a problem hiding this comment.
This is the first part of my review. I want to make sure I understand the intentions before completing it.
Tell me if I have the main idea of what this is solving. Previously, names referenced by globally defined function literals were not being verified to have been defined. These changes use this unique case as an entrypoint to recursively analyze all of the function literal's statements to ensure that all names referenced are actually defined.
Otherwise, please see the couple of comments I've left.
Yes, that is correct. |
Kouteki
modified the milestones:
🏗4️⃣ test4.gno.land [POST LAUNCH],
⏭️Next after mainnet
# Problem Definition The problem originates from the issue described in [#1135](#1135). While the full scope of the issue is broader, it fundamentally relates to the concept of loop variable escapes block where it's defined. e.g. 1: ```go package main import "fmt" var s1 []*int func forLoopRef() { defer func() { for i, e := range s1 { fmt.Printf("s1[%d] is: %d\n", i, *e) } }() for i := 0; i < 3; i++ { z := i + 1 s1 = append(s1, &z) } } func main() { forLoopRef() } ``` e.g. 2: ```go package main type f func() var fs []f func forLoopClosure() { defer func() { for _, f := range fs { f() } }() for i := 0; i < 3; i++ { z := i fs = append(fs, func() { println(z) }) } } func main() { forLoopClosure() } ``` e.g. 3: ```go package main func main() { c := 0 closures := []func(){} loop: i := c closures = append(closures, func() { println(i) }) c += 1 if c < 10 { goto loop } for _, cl := range closures { cl() } } ``` # Solution ideas - **identify escaped vars in preprocess**: Detect situations where a loop variable is defined within a loop block(including `for/range` loops or loops constructed using `goto` statements), and escapes the block where it's defined. - **runtime allocation**: Allocate a new heap item for the loop variable in each iteration to ensure each iteration operates with its unique variable instance. - **NOTE1**: this is consistent with Go's Strategy: "Each iteration has its own separate declared variable (or variables) [Go 1.22]. The variable used by the first iteration is declared by the init statement. The variable used by each subsequent iteration is declared implicitly before executing the post statement and initialized to the value of the previous iteration's variable at that moment." - **NOTE2**: the `loopvar` feature of Go 1.22 is not supported in this version, and will be supported in next version. not supporting capture `i` defined in for/range clause; ```go for i := 0; i < 3; i++ { s1 = append(s1, &i) } ``` # Implementation Details **Preprocess Stage(Multi-Phase Preprocessor)**: - **Phase 1: `initStaticBlocks`**: Establish a cascading scope structure where `predefine` is conducted. In this phase Name expressions are initially marked as `NameExprTypeDefine`, which may later be upgraded to `NameExprTypeHeapDefine` if it is determined that they escape the loop block. This phase also supports other processes as a prerequisite[#2077](#2077). - **Phase 2: `preprocess1`**: This represents the original preprocessing phase(not going into details). - **Phase 3: `findGotoLoopDefines`**: By traversing the AST, any name expression defined in a loop block (for/range, goto) with the attribute `NameExprTypeDefine` is promoted to `NameExprTypeHeapDefine`. This is used in later phase. - **Phase 4: `findLoopUses1`**: Identify the usage of `NameExprTypeHeapDefine` name expressions. If a name expression is used in a function literal or is referrnced(e.g. &a), and it was previously defined as `NameExprTypeHeapDefine`, the `used` name expression is then given the attribute `NameExprTypeHeapUse`. This step finalizes whether a name expression will be allocated on the heap and used from heap. `Closures` represent a particular scenario in this context. Each closure, defined by a funcLitExpr that captures variables, is associated with a HeapCaptures list. This list consists of NameExprs, which are utilized at runtime to obtain the actual variable values for each iteration. Correspondingly, within the funcLitExpr block, a list of placeholder values are defined. These placeholders are populated during the doOpFuncLit phase and subsequently utilized in the `doOpCall` to ensure that each iteration uses the correct data. - **Phase 5: `findLoopUses2`**: Convert non-loop uses of loop-defined names to `NameExprTypeHeapUse`. Also, demote `NameExprTypeHeapDefine` back to `NameExprTypeDefine` if no actual usage is found. Also , as the last phase, attributes no longer needed will be cleaned up after this phase. **Runtime Stage**: 1. **Variable Allocation**: - Modify the runtime so that encountering a `NameExprTypeHeapDefine` triggers the allocation of a new `heapItemValue` for it, which will be used by any `NameExprTypeHeapUse`. 2. **Function Literal Handling**: - During the execution of `doOpFuncLit`, retrieve the `HeapCapture` values (previously allocated heap item values) and fill in the placeholder values within the `funcLitExpr` block. - When invoking the function (`doOpCall`), the `placeHolder` values(fv.Captures) are used to update the execution context, ensuring accurate and consistent results across iterations. --------- Co-authored-by: ltzMaxwell <[email protected]> Co-authored-by: Morgan <[email protected]>
petar-dambovaliev
removed request for
moul,
piux2,
a team,
ajnavarro and
zivkovicmilos
Kouteki
requested review from
zivkovicmilos,
deelawn and
aeddi
and removed request for
zivkovicmilos and
deelawn
|
Added @aeddi to work in parallel on test coverage |
There was a problem hiding this comment.
mostly good, left some improve suggestions. @petar-dambovaliev
| } | ||
|
|
||
| // Error: | ||
| // main/files/closure.gno:7:5: constant definition loop with a |
There was a problem hiding this comment.
the error message in accurate(I know it's left over from before)
| @@ -3073,6 +3073,237 @@ func findUndefined(store Store, last BlockNode, x Expr) (un Name) { | |||
| return findUndefined2(store, last, x, nil) | |||
| } | |||
|
|
|||
| // finds the next undefined identifier and returns it if it is global | |||
| func findUndefined2SkipLocals(store Store, last BlockNode, x Expr, t Type) Name { | |||
| name := findUndefined2(store, last, x, t) | |||
There was a problem hiding this comment.
| name := findUndefined2(store, last, x, t) | |
| name := findUndefined2(store, last, x, t) | |
| if name == ""{ | |
| return "" | |
| } |
| @@ -3073,6 +3073,237 @@ func findUndefined(store Store, last BlockNode, x Expr) (un Name) { | |||
| return findUndefined2(store, last, x, nil) | |||
| } | |||
|
|
|||
| // finds the next undefined identifier and returns it if it is global | |||
| func findUndefined2SkipLocals(store Store, last BlockNode, x Expr, t Type) Name { | |||
There was a problem hiding this comment.
please consider this:
package main
var myDep string
var myVar2 = func() {
aaa := ""
myDep2 := "yeah"
switch aaa {
case myDep:
println(myDep2)
}
}
var myDep2 = "hey"
func main() {
myVar2()
}in the current situation, while dealing with switch aaa, aaa is deemed un -> not global, it's not local either(at the moment the previous aaa := "" has not been preprocessed(but it's been predefined, so the name exists in block).
the situation is same for myDep2, when dealing with println(myDep2), the global value declaration var myDep2 = "hey" is conducted even it's shadowed by the local myDep2 := "yeah". the reason is all the same, at this moment, the XXX is not global nor local.
I think the potential way to improve is to modify findUndefined2(or just another func), to return another result to represent if it's local predefined or global predefined or else.
There was a problem hiding this comment.
This correctly prints yeah. The code does not illustrate the problem.
This is the illustration of the problem
var myDep string
var myVar2 = func() {
aaa := ""
myDep2 := "yeah"
switch aaa {
case myDep:
println(myDep2)
}
}
var myDep2 = func() {
myVar2()
}myVar2 does not respect the shadowing.
There was a problem hiding this comment.
The problem is the usage of findUndefined2 here.
func findUndefined2SkipLocals(store Store, last BlockNode, x Expr, t Type) Name {
name := findUndefined2(store, last, x, t)
🛠 PR Checks Summary🔴 The pull request head branch must be up-to-date with its base (more info) Manual Checks (for Reviewers):
Read More🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers. ✅ Automated Checks (for Contributors):🔴 The pull request head branch must be up-to-date with its base (more info) ☑️ Contributor Actions:
☑️ Reviewer Actions:
📚 Resources:Debug
|
fixes this by adding missing logic in in
findUndefined2