Skip to content
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

If a var holding a proc is assigned from a case statement, its "nosideeffect" state is set to that of the first arm of case statement #12642

Closed
kaushalmodi opened this issue Nov 11, 2019 · 0 comments

Comments

@kaushalmodi
Copy link
Contributor

kaushalmodi commented Nov 11, 2019

If a proc-holding var is assigned a value using a case statement, it's "noSideEffect" state is set to the one from the first arm of the case statement. i.e. if the second or later arm of the case has a proc with side effects, it will fail compilation.

So can one of these be made possible:

  • Force the "side effect state" of a proc even if it actually has no side effects
  • Force the "side effect state" of a proc holding var
  • If a var is assigned from a case statement as in this example, its "side effect state" should be "has side effects" irrespective of the order of the case statement cases.

Example t12642.nim

https://play.nim-lang.org/#ix=21tP

# fails ->  nim c t12642.nim
# passes -> nim c -d:workaround t12642.nim

let
  choice = 0

proc withoutSideEffects(): int = 0
proc withSideEffects(): int = echo "foo" # the echo causes the side effect

when defined(workaround):
  # Workaround is to put the proc *without* side effects at the end of the
  # case statement.
  let procPtr = case choice
                of 0: withSideEffects
                else: withoutSideEffects
else:
  let procPtr = case choice
                of 0: withoutSideEffects
                else: withSideEffects

echo procPtr.repr

Run nim c t12642.nim.

Current Output

Error: type mismatch: got <proc (): int{.gcsafe, locks: 0.}> but expected 'proc (): int{.noSideEffect, gcsafe, locks: 0.}'

Expected Output

Should have printed the addr of the procPtr.

Workaround

Re-arrange the case statement so that the first case is the one where the proc with side effects is assigned,

But this workaround is not very robust, because tomorrow if the withSideEffects proc gets refactored to have no side effects, the case statement might need to be shuffled again.

So running nim c -d:workaround t12642.nim will work.

Additional Information

$ nim -v
Nim Compiler Version 1.1.1 [Linux: amd64]
Compiled at 2019-11-11
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: 7e689873e203620c3a14f1697129cd0e3fd548e4
active boot switches: -d:release

Update (2021/06/10):

I am re-confirming this issue on the latest devel:

Nim Compiler Version 1.5.1 [Linux: amd64]
Compiled at 2021-06-10
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 19918ceb2b099440cd3e43b6d7fff313de6a84a2
active boot switches: -d:release
Araq added a commit that referenced this issue Sep 6, 2021
@Araq Araq closed this as completed in 34a53e8 Sep 6, 2021
PMunch pushed a commit to PMunch/Nim that referenced this issue Mar 28, 2022
* fixes nim-lang#12642

* update important packages; refs nim-lang#18804

* fixes nim-lang#18805; refs nim-lang#18806

* fixes a regression

* Update testament/categories.nim

Co-authored-by: flywind <xzsflywind@gmail.com>

* progress

* progress

Co-authored-by: flywind <xzsflywind@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants