fix: achieve type assertion parity with go

[deelawn]

Fixes #1650

This PR was originally intended to fix the case described in issue #1650, but it soon became apparent that there were other subtle inconsistencies between type assertions in go vs gno. The changes outlined here attempt to fix the issues and the new file tests ensure correctness. The summary below provides details as to the cases that were fixed for type assertions, both 1 and 2 -- 1 and 2 referring to the type assertion op codes, OpTypeAssert1 and OpTypeAssert2. The former handles type assertions with one LHS argument that panic on assertion failure and the latter handles those with two LHS arguments that assigns a boolean value dependent on success or failure.

Summary of type assertion changes

• fail when the value being asserted has a nil type (i.e. the result of recover() when no panic has occurred). This applies for both cases where the type being asserted to is an interface or concrete type.
• fail when asserting to an interface type and the underlying type of the value being asserted is also an interface type (non-concrete type)

Also, is this an accurate assumption?

gno/gnovm/pkg/gnolang/op_expressions.go

Line 261 in 7d4e8e6

// If the underlying native type is reflect.Interface kind, then this has no

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.25%. Comparing base (229bf0e) to head (7685853).
Report is 17 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1689      +/-   ##
==========================================
+ Coverage   45.10%   48.25%   +3.15%     
==========================================
  Files         464      408      -56     
  Lines       68039    62354    -5685     
==========================================
- Hits        30689    30092     -597     
+ Misses      34774    29752    -5022     
+ Partials     2576     2510      -66     

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

[ltzmaxwell]

Hey nice work. took a peek mostly good. here are some of my questions:

1. Please take a look at this one:

package main

type ex int

func (ex) Error() string { return "" }

func main() {
	r := []int(nil)
	_, ok := r.(ex)
	println(ok)
}

// Output:
// false

// Go_Output:
// invalid operation: r (variable of type []int) is not an interface

the behavior is inconsistent with go. in this case, r has a static type of []int, so it actually can not be asserted to another concrete type.

2. And this one, this should be another problem actually:

package main

type ex int

func (ex) Error() string { return "" }

func main() {
	defer func() {
		r := _.(ex)
		println(r)
	}()
}

// Error:
// nil is not of type main.ex


// Go_Error:
// cannot use _ as value or type

3. third one:

package main

type A interface {
	Do(s string)
}

func main() {
	defer func() {
		e := recover()
		_ = e.(A)
	}()
}

// Error:
// nil doesn't implement main.A

// Go_Error:
// panic: interface conversion: interface is nil, not main.A

This pertains to the error message related to type assertions. According to the Go language specification, type assertions only happens from an interface type to other types. see https://go.dev/ref/spec#Type_assertions

[deelawn]

@ltzmaxwell so is it only the first case where the behavior is different between go and gno? The behavior of exampels 2 and 3 appear to be the same -- just the error messages are different. I'll fix the first and look at the ease of changing these error messages to something more specific.

[deelawn]

@ltzmaxwell I've made changes to address your comments. Let me know what you think.