feat(gnovm): interrealm spec; cross/crossing; readonly; defer/recover/panic fixes; blank identifier fixes....

[jaekwon]

This uses heapitemvalues more such that a closure or pointer doesn't need to refer to a block.
It resolves #3693.

Excerpt from the new document 'Gno Memory Model' in this PR:

---

func Example(arg int) (res *int) {
	var x int = arg + 1
	return &x
}

The above code when executed will first produce the following block:

BlockValue{
    ...
    Source: <*FuncDecl node>,
    Values: [
        {T: nil, V: nil},                      // 'arg' parameter
        {T: nil, V: nil},                      // 'res' result
        {T: HeapItemType{},
	 V: &HeapItemValue{{T: nil, V: nil}},  // 'x' variable
    ],
    ...
}

In the above example the third slot for x is not initialized to the zero
value of a typed value slot, but rather it is prefilled with a heap item.

Variables declared in a closure or passed by reference are first discovered and
marked as such from the preprocessor, and NewBlock() will prepopulate these
slots with *HeapItemValues. When a *HeapItemValue is present in a block
slot it is not written over but instead the value is written into the heap
item's slot.

When the example code executes return &x instead of returning a
PointerValue with .Base set to the BlockValue and .Index of 2, it sets
.Base to the *HeapItemValue with .Index of 0 since a heap item only
contains one slot. The pointer's .TV is set to the single slot of of the heap
item. This way the when the pointer is used later in another transaction there
is no need to load the whole original block value, but rather a single heap
item object. If Example() returned only x rather than a pointer &x it
would not be initialized with a heap item for the slot.

func Example2(arg int) (res func()) {
	var x int = arg + 1
	return func() {
		println(x)
	}
}

The above example illustrates another use for heap items. Here we don't
reference x, but it is captured by the anonymous function literal (closure).
At runtime the closure *FuncValue captures the heap item object such that the
closure does not depend on the block at all.

Variables declared at the package (global) level may also be referred to by
pointer in anonymous functions. In the future we will allow limited upgrading
features for mutable realm packages (e.g. the ability to add new functions or
replace or "swizzle" existing ones), so all package level declared variables
are wrapped in heap item objects.

Since all global package values referenced closures can be captured as heap
objects, the execution and persistence of a closure function value does not
depend on any parent blocks. (Omitted here is how references to package
level declared functions and methods are replaced by a selector expression
on the package itself; otherwise closures would still in general depend
on their parent blocks).

Loopvars

Go1.22 introduced loopvars to reduce programmer errors. Gno uses
heap items to implement loopvars.

for _, v := range values {
    saveClosure(func() {
        fmt.Println(v)
    })
}

The Gno VM does something special for loopvars. Instead of assigning the new
value v to the same slot, or even the same heap item object's slot, it
replaces the existing heap item object with a new one. This allows the closure
to capture a new heap item object with every iteration. This is called
a heap definition.

The behavior is applied for implicit loops with goto statements. The
preprocessor first identifies all such variable definitions whether explicit in
range statements or implicit via goto statements that are captured by
closures or passed by pointer reference, and directs the VM to execute the
define statement by replacing the existing heap item object with a new one.

[Gno2D2]

🛠 PR Checks Summary

🔴 Changes to 'docs' folder must be reviewed/authored by at least one devrel and one tech-staff

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🔴 Changes to 'docs' folder must be reviewed/authored by at least one devrel and one tech-staff

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Changes to 'docs' folder must be reviewed/authored by at least one devrel and one tech-staff

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 A changed file matches this pattern: ^docs/ (filename: docs/resources/gno-interrealm.md)

Then

🔴 Requirement not satisfied
└── 🔴 And
    ├── 🟢 Or
    │   ├── 🟢 Pull request author is a member of the team: tech-staff
    │   └── 🟢 At least 1 user(s) of the team tech-staff reviewed pull request(with state "APPROVED")
    └── 🔴 Or
        ├── 🔴 Pull request author is a member of the team: devrels
        └── 🔴 At least 1 user(s) of the team devrels reviewed pull request(with state "APPROVED")

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[ltzmaxwell]

update can be a heap item, since all global variables are stored as heap item values. Therefore, a check is needed to determine whether update is a heap item. If it is, do not call GetFirstObject, as this would trigger a panic. thanks @leohhhn for discovering the initial bug.

[jaekwon]

Hmm, maybe it should just work for heap items too now.
Is there a bug report or way to reproduce, or associated test that fails?
7777.

[moul]

I just merged the master branch into this PR. I'm 90% confident that I resolved the conflicts correctly.

[codecov]

Codecov Report

Attention: Patch coverage is 80.05249% with 76 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/pkg/gnolang/machine.go	78.75%	13 Missing and 4 partials ⚠️
gnovm/pkg/gnolang/ownership.go	51.61%	14 Missing and 1 partial ⚠️
gnovm/pkg/gnolang/nodes.go	72.72%	6 Missing and 3 partials ⚠️
gnovm/pkg/gnolang/op_expressions.go	79.54%	8 Missing and 1 partial ⚠️
gnovm/pkg/gnolang/preprocess.go	91.01%	6 Missing and 2 partials ⚠️
gnovm/pkg/gnolang/types.go	64.70%	6 Missing ⚠️
gnovm/pkg/gnolang/values.go	92.59%	3 Missing and 1 partial ⚠️
gnovm/pkg/gnolang/uverse.go	50.00%	3 Missing ⚠️
gnovm/pkg/gnolang/helpers.go	33.33%	2 Missing ⚠️
gnovm/stdlibs/std/native.go	81.81%	2 Missing ⚠️
... and 1 more

📢 Thoughts on this report? Let us know!

[moul]

btw, please check this commit: 25bf34c (#4060)

[jaekwon]

this needs change.

[jaekwon]

interrealm cross & crossing

[jaekwon]

no realm crossing

[jaekwon]

btw, please check this commit: 25bf34c (#4060)

seems like it needs fixing, I'll take a look. The // 2 1 --> // 1 2 seems correct but the // undefined isn't consistent with go...

[jaekwon]

this was incorrect.