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

Include statement created by macro doesn't work #8038

Open
demotomohiro opened this issue Jun 14, 2018 · 5 comments
Open

Include statement created by macro doesn't work #8038

demotomohiro opened this issue Jun 14, 2018 · 5 comments

Comments

@demotomohiro
Copy link
Contributor

testcode.nim:

echo "echo from testcode.nim"

inclmacro.nim:

import macros

#This include statement works
include "testcode.nim"

dumpTree:
    include "testcode.nim"
#    include "/tmp/tmp/testcode.nim"

macro inclMacro(): untyped =
    result = newStmtList()

    let incl = newNimNode nnkIncludeStmt 
    incl.add newStrLitNode("testcode.nim")
#Using absolute path is fine.
#    incl.add newStrLitNode("/tmp/tmp/testcode.nim")
    result.add incl

    #Output of following echo is equivalent to above dumpTree
    echo treeRepr(result)

inclMacro()

Compiling inclmacro.nim output following error:

$ nim c -r inclmacro.nim
Hint: used config file '/usr/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: inclmacro [Processing]
Hint: macros [Processing]
StmtList
  IncludeStmt
    StrLit testcode.nim
StmtList
  IncludeStmt
    StrLit testcode.nim
inclmacro.nim(21, 10) template/generic instantiation from here
lib/core/macros.nim(274, 22) Error: cannot open 'testcode.nim'

Plain include statement in inclmacro.nim works without errors, but calling macro that makes equivalent include statement cause "cannot open" error.
When I use inclMacro macro with absolute path of testcode.nim, above error doesn't happen.
It seems current working directory was changed to somewhere when I use include statement in macro.

LemonBoy added a commit to LemonBoy/Nim that referenced this issue Sep 17, 2018
Do not use the node infos since those may be inaccurate or fabricated by
the user.

For example it is extremely easy common to have literal nodes produced
by helper functions in `macros.nim` whose info points to `macros.nim`
itself.

Fixes nim-lang#7466
Fixes nim-lang#8038
@demotomohiro
Copy link
Contributor Author

I tested this issue with Nim 1.0.99.

Nim Compiler Version 1.0.99 [Windows: amd64]
Compiled at 2019-10-17
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: a5ab502f08d11be807c663a9d586b4a4768772dc
active boot switches: -d:release

But still the issue is not fixed.
According to comments in related issue, when import or include statements are created by macro, a relative path in these statement is relative to macros.nim, not relative to the file calling the macro.
If I want to create import or include statements by macro, I have to use absolute path.

@krux02
Copy link
Contributor

krux02 commented Oct 18, 2019

workaround: use quote do:, this will set the lineinfo for the include statement correctly.

import macros

include "testcode.nim"

dumpTree:
    include "testcode.nim"

macro inclMacro(): untyped =

    let strLit = newStrLitNode("testcode.nim")

    result = quote do:
      include `strLit`

    echo treeRepr(result)

inclMacro()

output:

echo from testcode.nim
echo from testcode.nim

@bluenote10
Copy link
Contributor

For slurp/gorge/... I noticed the same behavior. In this case I could make it work by setting the lineinfo of generated AST explicitly to the lineinfo of the call site, see here. Maybe this works for include as well.

@krux02
Copy link
Contributor

krux02 commented Oct 18, 2019

callsite doesn't properly work in macros, but year sure that would be a good idea, since workaround sets the lineinfo to the directory of the macro, not the directory of the macro expansion.

@krux02
Copy link
Contributor

krux02 commented Oct 18, 2019

BTW, before you base any logic on this behavior, please also commit some tests that ensure that Nim won't break this behaviour without notice. I have a feeling that there might be a breaking change in the future and nobody would notice it.

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

4 participants