-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
for i in range(10) crashes the compiler #605
Comments
Here's a gist with more information on the segfault. The compiler was built from the latest revision, on windows 64 as a 64-bit executable, in debug mode (for the tracebacks) |
This crashes on OSX as well. |
While this shouldn't segfault, range is not a proc, but a type generator: http://nimrod-code.org/system.html#148 So the code snippet doesn't really make sense. I believe this would be idiomatic:
|
OK, that's what I thought I was not sure if there was also a proc named "range" that I wasn't aware of. |
There is something funny going on here...
I'm not sure what
|
Ok, the last three function calls in the stack trace are where the damage is being done, I think. |
This now produces a slightly confusing, but still valid error message: Error: conversion from int literal(10) to range is invalid |
605: template non-ast param limited to lookup substitution r=zerbina a=saem ## Summary * non-ast params (excluding `typed` and `untyped`) are only substituted for usage positions * where a usage positionis is any syntactic position where a symbol is not intended to be introduced * in additition, the manual and semtempl module have some doc comments outlining the new direction for templates ## Details Starting with a motivating example, this now works after the change: ```nim template foo(data: int): untyped = proc bar(data: int): int = 2 * data bar(data) doAssert foo(2) == 4 ``` The reason this works now is `data` the template arg is a non-ast type, it's not substituted into `data` the proc param, and `data` the proc param is instead converted into a symbol. This means that when `data` the proc body usage is looked up, it's lexically resolved with `data` the proc param. Finally, when `data` the call argument's usage is looked up, the template param is found and substituted. ### Further Details Template parameters that are neither `typed` or `untyped` will no longer subsititute for definitional syntax positions, or syntax positions that meant to introduce routines, variables, types and other named definitions. For non-ast typed substitution lexical scope based lookups are used. AST typed template parameter substitutions continue to work as is, since they're arbitrary symbolic substitutions. This makes more sense given that we're substituting syntactic symbol usage as opposed to syntactic symbol introductions; but it also removes a vector by which symbol pollution can take place. As templates have lots of rough edges in implementation there are still many bugs, but these are almost entirely pre-existing. ### Overview of Concepts Introduced: This is a brief overview, see the module and docs for more info, also this is developing, these are still mostly in docs: * the concept of template substitution being policy being set by template output type has been introduced * a template body is to be thought of as an out parameter with the same type as the template output * additionally, a template body can be considered as a form of quasi quoting, where the type determines how we treat the substitution of various kinds of parameters (ast and non-ast types). Co-authored-by: saem <saemghani+github@gmail.com>
This code causes SEGFAULT on compiler:
The text was updated successfully, but these errors were encountered: