fix: solve problem that variable (of declaredType) is not assigned with correct type

[ltzmaxwell]

code like this won't work. when abs is assigned like this: abs = []Word{0}, abs is assigned with a type of []Word, thus abs.add3() does not work.

type nat3 []Word
type Word uint


func (n nat3) add3() bool {
	return true
}

func main() {
	var abs nat3
	abs = []Word{0}
	abs.add3()
}

another example, abs is a nested field:

type nat3 []Word
type Word uint

type Int3 struct {
	neg bool
	abs nat3
}

func (n nat3) add3() bool {
	return true
}

func main() {
	z := &Int3{
		neg: true,
		abs: []Word{0},
	}
	z.abs.add3()
}

The problem come from : #651 .

The solution is to give proper type to variable with declaredType.

[ltzmaxwell]

Hi, @r3v4s , would you check this.

[piux2]

@ltzmaxwell good findings! We are definitely in the right direction.

However, there are a lot of changes. Can you help describe the root cause and why the fix solved the problem?

I noticed a side effect in this test case.
examples/gno.land/r/demo/nft/z_0_filetest.gno

https://github.com/gnolang/gno/pull/674/files#diff-5a26a017ddff81d0ef1a36c2190cab1fedc6eac9cee7e404c62bc7a3bb73c303L54

//             "T": {
//             -    "@type": "/gno.PrimitiveType",
//              -  "value": "16"
//              +   "@type": "/gno.RefType",
//              +   "ID": "gno.land/p/demo/grc/grc721.TokenID"
//             },
//             "V": {
//                 "@type": "/gno.StringValue",
//                 "value": "NFT#1"
//             }
//         }

 type NFToken struct {
        owner    std.Address
        approved std.Address
        tokenID  grc721.TokenID
        data     string
    }

Above is the "data" field metadata in an NFTToken instance. The value is "NFT#1"
Its Type should be

"@type": "/gno.PrimitiveType", "value": "16"

instead of

@type": "/gno.RefType", "ID": "gno.land/p/demo/grc/grc721.TokenID"

[ltzmaxwell]

Thank you @piux2 , it's actually a bug, I'm giving fix.

[ltzmaxwell]

@peter7891 is ok for review

[jaekwon]

Do not merge, please see #651 (comment)

Also please add me as a reviewer for all gnolang vm changes!

[ltzmaxwell]

WIP, block.

[ltzmaxwell]

Hi @jaekwon , Can you take a look at this? Thank you!

update:

1.enhanced preprocessing. An explicit conversion from unnamed-composite to named declared types has now been implemented. This solution addresses the majority of the issues encountered previously.

2.The copy function has also been fixed. According to the Go specification, "The core types of both arguments must be slices with identical element types". Our previous implementation lacked this necessary check, so we have now added it for improved robustness.

[ltzmaxwell]

Hi, @jaekwon , I have another question, currently the code below would not work since n2 is not assigned with correct type from the assignment. It works in go playground: https://go.dev/play/p/pA0cqF-nuBV

the question is whether we can fix it in preprocess stage?
In case like, a, b = x, y., when traverse into AssignStmt node in preprocess, the Rhs can be easily converted to the target type , but in case like n1, n2 = x() , seems we can not do the same thing without a list of result Exprs of the CallExpr?

Thank you!

package main

type nat []int

func (n nat) add() bool {
	return true
}

func x() (nat, []int) {
	a := nat{0}
	b := []int{1}
	return a, b
}

func main() {
	var n1, n2 nat

	n1, n2 = x()

        n1.add()
	n2.add()

}

[jaekwon]

this is the solution we want: https://gist.github.com/piux2/49bada7be72186371e6684d007d3ed75?permalink_comment_id=4579166#gistcomment-4579166 links to https://github.com/gnolang/gno/compare/master...piux2:gno:fix_declaredtype_preprocess?expand=1 .

The thread on piux2's thread (first link) has comments on improvements and what is necessary to make complete.

To answer your exact question, yes we can and we will, but the simplest solution for now is to do the following:

// pseudocode
// on LEAVE AssignStmt around 1574 for `case *CallExpr:`
    ...
    if dest type is interface type { 
        ...
    } else if leftType is exactly rightType {
        // perfect match, continue
    } else if checkType(leftType, rightType) {
        panic("a, b := x() implicit conversion not supported yet")
    } else {
        panic("type check error")
    }

Ray has the context to complete this. Then, you can work with Ray to complete the next PR which is to do the expansion only when necessary.

[jaekwon]

right, right. this would make sense (or it could just return the value as a bool, i think is simpler) to get the information out of the function. we will need this later for the full unroll solution (e.g. the second pr after ray's), but I suggest a return bool value instead.

[jaekwon]

what prompted this? seems like this could/should be a separate PR for complete discussion. seems correct though.

[ltzmaxwell]

It's a fix of copy function. According to the Go specification, "The core types of both arguments must be slices with identical element types". Our previous implementation lacked this necessary check.

I'll put it into another PR. Thank you~

[jaekwon]

we can close this or @piux2 can merge here.

[ltzmaxwell]

house keeping.