Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.75%. Comparing base (a1a7cb3) to head (db1e4a6).
Report is 2 commits behind head on master.

@@            Coverage Diff             @@
##           master    #3135      +/-   ##
==========================================
- Coverage   63.79%   63.75%   -0.05%     
==========================================
  Files         549      549              
  Lines       78819    79449     +630     
==========================================
+ Hits        50281    50651     +370     
- Misses      25146    25380     +234     
- Partials     3392     3418      +26     

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

@onlyhyde @notJoon @r3v4s

It seems to work, unless we consider the current behavior a bug that we want to fix. In that case, we can create gno object registries by avoiding the storage of remotely defined objects. Instead, we can store remotely defined functions that dynamically return the remote object when needed.

I’m not a big fan of this indirection because I believe Go interfaces are excellent. However, since we fully preserve Go's type safety, I think it’s a good compromise that allows for greater independence between realms.

The last checkbox in the original comment raises an open question about how we plan to manage realm deprovisionning in the future. One idea I have that would avoid the need to track which remote realms are storing a locally defined function (remote backref). We could implement a special rule in the VM so that if you:

1. Store a remotely defined function,
2. Deprovision the remote realm,
3. Attempt to call the locally stored (now dead) function, instead of panicking, we could simulate that the pointer is now nil at runtime.

This would mean we only need to check if the pointer is nil to manage custom error handling, or we could allow the VM to panic due to the missing pointer.

Did you try to call mutating functions from the calling realm?
The tests seem to be read-only

I have some tests that perform mutations. However, if you want an advanced case, check out #2510 (comment).

Can you link the mutation tests pls? I can't find them

On the atomic swap branch, the swap with registered token is not tested currently.
I added the test and it doesn't work

PR: moul#21
Test result:

❯ go run ./gnovm/cmd/gno test ./examples/gno.land/r/demo/atomicswap                                                                                                                 Native
--- FAIL: TestNewGRC20Registered_Claim (0.00s)
uassert.Equal: same type but different value
	expected: 60000
	actual:   30000
uassert.Equal: same type but different value
	expected: 70000
	actual:   0
uassert.Equal: same type but different value
	expected: 60000
	actual:   30000
uassert.Equal: same type but different value
	expected: 140000
	actual:   70000
./examples/gno.land/r/demo/atomicswap: test pkg: failed: "TestNewGRC20Registered_Claim"
FAIL
FAIL    ./examples/gno.land/r/demo/atomicswap 	1.17s
FAIL
FAIL
FAIL: 0 build errors, 1 test errors
exit status 1

Just FYI we have this pattern on teritori repo for a long time but mutations never worked (https://github.com/TERITORI/teritori-dapp/blob/main/gno/r/dao_registry/dao_registry.gno)

Here's one: https://github.com/gnolang/gno/pull/3135/files#diff-57ef3b955ce6dd26e824d52cfa9fd0d84e2b4f67e50abdd3f5d117458a14e59cR15

You're right; the atomic swap wasn't tested, and I forgot to remove a "panic not implemented" blocker. However, the test output you shared isn't related to mutation. It's due to reusing the same "sender" and "recipient" addresses in independent tests. In other words, if you run a single unit test with -run, it works, but running everything together does not. Here is a commit that makes the sender and recipient independent for each test: 3a5acf1.

And here a21ddd5 is the commit that removes the panic and adds the missing tests for atomic swap. It works.

$>  gno test -v ./examples/gno.land/r/demo/atomicswap
=== RUN   TestNewCustomCoinSwap_Claim
--- PASS: TestNewCustomCoinSwap_Claim (0.00s)
=== RUN   TestNewCustomCoinSwap_Refund
--- PASS: TestNewCustomCoinSwap_Refund (0.00s)
=== RUN   TestNewCustomGRC20Swap_Claim
--- PASS: TestNewCustomGRC20Swap_Claim (0.00s)
=== RUN   TestNewCustomGRC20Swap_Refund
--- PASS: TestNewCustomGRC20Swap_Refund (0.00s)
=== RUN   TestNewGRC20Swap_Claim
--- PASS: TestNewGRC20Swap_Claim (0.00s)
=== RUN   TestNewGRC20Swap_Refund
--- PASS: TestNewGRC20Swap_Refund (0.00s)
=== RUN   TestRender
--- PASS: TestRender (0.00s)
ok      ./examples/gno.land/r/demo/atomicswap   1.44s

1. this pattern is no different with this, except for the addition of Getter for convenience, right?

// PKGPATH: gno.land/r/crossrealm_test
package crossrealm_test

import (
	"std"

	crossrealm "gno.land/r/demo/tests/crossrealm"
)

type fooer struct {
	v string
}

func (f *fooer) Foo() { println("hello " + f.v + " " + std.CurrentRealm().PkgPath()) }

func (f *fooer) Mutate() {
	f.v = "b"
}

var f *fooer

func init() {
	f = &fooer{v: "a"} // attach first
}

func main() {
	crossrealm.SetFooer(f)
	crossrealm.CallFooerFoo()

	crossrealm.MutateFooer()
	crossrealm.CallFooerFoo()
}

// Output:
// hello a gno.land/r/crossrealm_test
// hello b gno.land/r/crossrealm_test

2. There are underlying bugs that we need to fix (though they do not block the Getter pattern):

// PKGPATH: gno.land/r/crossrealm_test
package crossrealm_test

import (
	"std"

	crossrealm "gno.land/r/demo/tests/crossrealm"
)

type fooer struct {
	s string
}

func (f *fooer) Foo() {
	println("hello " + f.s + " " + std.CurrentRealm().PkgPath())
}

func (f *fooer) Mutate() {}

func init() {
	f := &fooer{s: "B"} // XXX, note this is incorrectly attached to "r/demo/crossrealm", by the next line.
	fg := func() crossrealm.Fooer { return f }
	crossrealm.SetFooerGetter(fg)
	crossrealm.CallFooerGetterFoo()

	f.s = "C" // XXX, so this cause a panic while modifying external realm obejct
	crossrealm.CallFooerGetterFoo()
}

func main() {
	print(".")
}

// Error:
// cannot modify external-realm or non-realm object