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

Const block in function cannot evaluate vars at compile time #21610

Closed
tsoj opened this issue Apr 2, 2023 · 1 comment · Fixed by #24674
Closed

Const block in function cannot evaluate vars at compile time #21610

tsoj opened this issue Apr 2, 2023 · 1 comment · Fixed by #24674

Comments

@tsoj
Copy link

tsoj commented Apr 2, 2023

Description

A compile time block in a function body doesn't allow the creation of vars. The following example fails to compile:

func stuff(): int =
  const r = block:
    var r = 0 # Error: cannot evaluate at compile time: r
    for i in 0..10:
      r *= i
    r
  r

echo stuff()

When the const block is outside the function, it works however:

const r = block:
  var r = 0
  for i in 0..10:
    r *= i
  r

func stuff(): int =
  r

echo stuff()

Nim Version

Nim Compiler Version 1.9.3 [Linux: amd64]
Compiled at 2023-04-01
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 1c7fd71
active boot switches: -d:release

Current Output

Hint: used config file '/home/tsoj/.choosenim/toolchains/nim-#devel/config/nim.cfg' [Conf]
Hint: used config file '/home/tsoj/.choosenim/toolchains/nim-#devel/config/config.nims' [Conf]
......................................................................
/tmp/main.nim(3, 9) Error: cannot evaluate at compile time: r

Expected Output

0

or if it's supposed to not compile, a better error message.

Possible Solution

No response

Additional Information

No response

@metagn
Copy link
Collaborator

metagn commented Apr 3, 2023

Similar/same #8758 #10828 #12172

metagn added a commit to metagn/Nim that referenced this issue Sep 8, 2024
metagn added a commit to metagn/Nim that referenced this issue Sep 10, 2024
metagn added a commit to metagn/Nim that referenced this issue Feb 8, 2025
Araq pushed a commit that referenced this issue Feb 14, 2025
fixes #8758, fixes #10828, fixes #12172, fixes #21610, fixes #23803,
fixes #24633, fixes #24634, succeeds #24085

We simply track the symbol ID of every traversed `var`/`let` definition
in `vmgen`, then these symbols are always considered evaluable in the
current `vmgen` context. The set of symbols is reset before every
generation, but both tests worked properly without doing this including
the nested `const`, so maybe it's already done in some way I'm not
seeing.
narimiran pushed a commit that referenced this issue Feb 17, 2025
fixes #8758, fixes #10828, fixes #12172, fixes #21610, fixes #23803,
fixes #24633, fixes #24634, succeeds #24085

We simply track the symbol ID of every traversed `var`/`let` definition
in `vmgen`, then these symbols are always considered evaluable in the
current `vmgen` context. The set of symbols is reset before every
generation, but both tests worked properly without doing this including
the nested `const`, so maybe it's already done in some way I'm not
seeing.

(cherry picked from commit a5cc33c)
narimiran pushed a commit that referenced this issue Mar 3, 2025
fixes #8758, fixes #10828, fixes #12172, fixes #21610, fixes #23803,
fixes #24633, fixes #24634, succeeds #24085

We simply track the symbol ID of every traversed `var`/`let` definition
in `vmgen`, then these symbols are always considered evaluable in the
current `vmgen` context. The set of symbols is reset before every
generation, but both tests worked properly without doing this including
the nested `const`, so maybe it's already done in some way I'm not
seeing.

(cherry picked from commit a5cc33c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants