fix: remove incorrect type assertion when reading values from storage

[deelawn]

Addresses #1588.

The following explanation refers to the txtar test linked to in the issue. Here it is for convenience.

Why the panic?

This line in the txtar test's Read() function caused the panic: out += post.CreatedAt.Format(time.RFC3339). The Format method results in invoking the Time.locabs method, and this is the line inside that method that caused the panic: https://github.com/gnolang/gno/blob/master/gnovm/stdlibs/time/time.gno#L468

The panic occurs when trying to resolve the value of l.cacheZone as a part of the selector operation. This is a panic caused by an invalid type assertion. The invalid type assertion happens on the line that was modified for this PR: https://github.com/gnolang/gno/blob/master/gnovm/stdlibs/time/time.gno#L468

In the case of this particular txtar test, the target value's base value is a struct value, not an array value. We can look at how the original cacheZone value was persisted to understand why the base type is different from what we'd expect.

Original value persistence

The original time value is built as a result of this line in the txtar test's Store() function: parsedTime, err = time.Parse(time.RFC3339, date).

The cacheZone value that is persisted either has a struct base value or is nil for the majority of this operation. However, the time value's Location field gets updated near the end of the parse operation and assumes the value of the result of the FixedZone function: https://github.com/gnolang/gno/blob/master/gnovm/stdlibs/time/format.gno#L1306

Taking a look at what FixedZone actually does, we can see that the location's cacheZone is now a reference to a zone that exists as a part of an array -- a struct with a base type of an array value: https://github.com/gnolang/gno/blob/master/gnovm/stdlibs/time/timezoneinfo.gno#L114

This explains why the value we were seeing when trying to resolve the cacheZone selector had an array base.

The fix

It doesn't matter if the source value's parent is an array or struct; we need the underlying value's type and value. That being said, I don't think the array type assertion needs to happen since the type value is accessible via the Elem() method defined as part of the Type interface. Now the value is obtained without causing a panic.

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

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (d1ead00) 55.80% compared to head (0b78d9d) 56.94%.
Report is 8 commits behind head on master.

Files	Patch %	Lines
gnovm/pkg/gnolang/values.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1606      +/-   ##
==========================================
+ Coverage   55.80%   56.94%   +1.14%     
==========================================
  Files         435      436       +1     
  Lines       66055    68245    +2190     
==========================================
+ Hits        36862    38863    +2001     
- Misses      26320    26386      +66     
- Partials     2873     2996     +123     

Flag	Coverage Δ
go-1.21.x	∅ <ø> (∅)
misc	∅ <ø> (∅)
misc-_test.genstd	∅ <ø> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[thehowl]

Thanks for the rich description!

[thehowl]

good to merge after @piux2 review :)

[jaekwon]

looking at this now, finally.