fix: invoke user recover with implicit panics

[petar-dambovaliev]

Currently only explicit panic invocations are recovered in the user code.
This PR covers the implicit panics that happen because of invalid operations.
Associated issue

This maintains the distinction between VM panics and user panics.

Here is a list of possible runtime panics that we will cover.

• Out-of-Bounds Slice or Array Access
• Invalid Slice Indexing
• Division by Zero and MOD zero
• Type Assertion Failure
• Invalid Memory Allocation (bad call to make())
• Out-of-Bounds String Indexing
• nil pointer dereference
• Write to a nil map

Also, fixed a small bug with the builtint function make.
It wasn't panicking when cap > len

[codecov]

Codecov Report

Attention: Patch coverage is 31.28834% with 112 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/pkg/gnolang/op_binary.go	19.19%	55 Missing and 25 partials ⚠️
gnovm/pkg/gnolang/values.go	33.33%	22 Missing and 2 partials ⚠️
gnovm/pkg/gnolang/op_assign.go	33.33%	2 Missing and 2 partials ⚠️
gnovm/pkg/gnolang/alloc.go	50.00%	1 Missing and 1 partial ⚠️
gnovm/pkg/gnolang/uverse.go	33.33%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[ltzmaxwell]

can you please add some tests for this?

[omarsy]

I tried a fix similar to this one: #2484, but my approach wasn't preferred. They favor an indiscriminate runtime panic, which complicates things for me (it is possible, but need a refactoring). I see two options:

1. Do not indiscriminate runtime panics (like your fix and my fix)
2. Accept that runtime errors are not recoverable

[petar-dambovaliev]

can you please add some tests for this?

its still WIP

[petar-dambovaliev]

can you please add some tests for this?

tests added

[mvertes]

Looks good to me

[omarsy]

GG for this PR, it's a great improvement! However, I have a small issue regarding some cases where error handling with recover doesn't seem to work as expected. For example, in the Gno Native packages, like this one:

package main

import "time"

func main() {
    defer func() {
        r := recover()
        println("recover:", r)
    }()
    t := time.Now()
    t.In(nil)  
}

The issue here is that t.In(nil) causes an error, but there's no recovery mechanism for this situation. However, since Gno Native will no longer be supported in the future, perhaps we don't need to handle this case at this point.

We also have cases where panic occurs when we inject Go code injected into a Gno package. For example, this code:

package test

import "std"

func main() {
    defer func() {
        r := recover()
        println("recover:", r)
    }()
    banker := std.GetBanker(std.BankerTypeRealmSend)
    banker.SendCoins(std.CurrentRealm().Addr(), "", std.Coins{{"ugnot", 2000000000}})
}

I’ve seen this kind of panic occur, and I’m unsure if this should be recoverable.

Also, consider this case:

package test

import "time"

func main() {
    defer func() {
        r := recover()
        println("recover:", r)
    }()
    println(time.UTC == nil)
    time.UTC = nil
}

This could also cause an issue, and I’m not sure if this is something we should be able to recover from.

Just wanted to raise these points, but again, great job on this PR!

[ltzmaxwell]

some comments from @omarsy to be resolved, but otherwise LGTM. I'll approve this after.

[ltzmaxwell]

We also have cases where panic occurs when we inject Go code injected into a Gno package. For example, this code:

package test

import "std"

func main() {
    defer func() {
        r := recover()
        println("recover:", r)
    }()
    banker := std.GetBanker(std.BankerTypeRealmSend)
    banker.SendCoins(std.CurrentRealm().Addr(), "", std.Coins{{"ugnot", 2000000000}})
}

I think this worth discussing, the defer is not executed as expected(maybe the panic is not needed to be recovered: it's not required for the actual functionality, but it feels a bit odd for developers.).

can you file another issue for this? @omarsy .