-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
type assertion on recovered nil
s panics
#1650
Milestone
Comments
thehowl
added
🐞 bug
Something isn't working
📦 🤖 gnovm
Issues or PRs gnovm related
labels
Feb 9, 2024
thehowl
changed the title
type assertion on recovered
type assertion on recovered Feb 9, 2024
nil
s is not possiblenil
s panics
note: this happened while attempting to use |
I was working on a fix for this and may have one, but encountered a separate issue while testing -- #1656. It would be good to get this fixed first so that any tests added along with this fix are certain to behave correctly. |
7 tasks
deelawn
added a commit
that referenced
this issue
May 21, 2024
<!-- please provide a detailed description of the changes made in this pull request. --> 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? https://github.com/gnolang/gno/blob/7d4e8e645ca1d2e89f5a8f2e85470e66b3253b33/gnovm/pkg/gnolang/op_expressions.go#L261 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
github-project-automation
bot
moved this from In Progress
to Done
in 🧙♂️gno.land core team
May 21, 2024
leohhhn
pushed a commit
to leohhhn/gno
that referenced
this issue
May 21, 2024
<!-- please provide a detailed description of the changes made in this pull request. --> Fixes gnolang#1650 This PR was originally intended to fix the case described in issue gnolang#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? https://github.com/gnolang/gno/blob/7d4e8e645ca1d2e89f5a8f2e85470e66b3253b33/gnovm/pkg/gnolang/op_expressions.go#L261 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Output and stacktrace
Note: this is not about asserting on
nil
in general; I suspect there's as always the internal pesky difference between an "initialised" and an "uninitialised" value. This code works:The text was updated successfully, but these errors were encountered: