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

generic, compile-time proc creates "cannot generate VM code for T" error #19365

Closed
tersec opened this issue Jan 11, 2022 · 1 comment · Fixed by #22029
Closed

generic, compile-time proc creates "cannot generate VM code for T" error #19365

tersec opened this issue Jan 11, 2022 · 1 comment · Fixed by #22029

Comments

@tersec
Copy link
Contributor

tersec commented Jan 11, 2022

A compile-time procedure with a generic, static type compiles with a VM code generation error.

Example

proc f[T](x: static T) {.compileTime.} = discard

Current Output

testcase.nim(1, 21) Error: cannot generate VM code for T

Expected Output

Successful compilation.

Tested with Nim versions:

Nim Compiler Version 1.2.16 [Linux: amd64]
Compiled at 2022-01-10
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: c6a9f27b3e36bae9aacec1bd6c37893fb98fd33f
active boot switches: -d:release
Nim Compiler Version 1.6.2 [Linux: amd64]
Compiled at 2021-12-17
Copyright (c) 2006-2021 by Andreas Rumpf

active boot switches: -d:release
Nim Compiler Version 1.7.1 [Linux: amd64]
Compiled at 2022-01-11
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 9888a29c3de09c73202b2a955e09e2a7b5e56ea4
active boot switches: -d:release
@metagn
Copy link
Collaborator

metagn commented Jun 6, 2023

Apparently this also fails?

proc f[T](x: static T) = discard

metagn added a commit to metagn/Nim that referenced this issue Jun 13, 2023
metagn added a commit to metagn/Nim that referenced this issue Aug 16, 2024
Araq pushed a commit that referenced this issue Aug 17, 2024
fixes #10753, fixes #22021, refs #19365 (was fixed by #22029, but more
faithful test added)

For whatever reason `compileTime` proc calls did not fold if the proc
was generic ([since this folding was
introduced](c25ffbf#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40)).
I'm guessing the intention was for *unresolved* generic procs to not
fold, which is now the logic.

Non-magic `compileTime` procs also now don't fold at compile time in
`typeof` contexts to avoid possible runtime errors (only the important)
and prevent double/needless evaluation.
narimiran pushed a commit that referenced this issue Sep 13, 2024
fixes #10753, fixes #22021, refs #19365 (was fixed by #22029, but more
faithful test added)

For whatever reason `compileTime` proc calls did not fold if the proc
was generic ([since this folding was
introduced](c25ffbf#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40)).
I'm guessing the intention was for *unresolved* generic procs to not
fold, which is now the logic.

Non-magic `compileTime` procs also now don't fold at compile time in
`typeof` contexts to avoid possible runtime errors (only the important)
and prevent double/needless evaluation.

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

Successfully merging a pull request may close this issue.

2 participants