Build fails when using --gc:arc.

[Wazubaba]

Hi! Sorry if this bug report doesn't follow any predefined template or guidelines as I didn't notice any info on one. Nim just updated the other day and moved the new arc GC to stable, so I am currently trying to prep a prototype in-house game engine tinker project to take advantage of it, which uses euwren for the scripting layer. Unfortunately, the build fails with:

# Resetting /home/[OMITTEDHOMEDIRNAME]/.cache/nim/nimterop/euwren
# Importing /home/[OMITTEDHOMEDIRNAME]/.cache/nim/nimterop/euwren/src/include/wren.h
fatal.nim(49)            sysFatal
Error: unhandled exception: 'sym' is not accessible using discriminant 'kind' of type 'TNode' [FieldError]

If I build with the default garbage collector or remove euwren and use arc, there appears to be no problem, so I'm fairly certain this isn't on my end (though if it is I do apologize for taking up your time). I don't mean to rush you or anything since this update just dropped (as of this report) yesterday, and frankly I can just disable that component on my end for now. I just wanted to make sure you were aware of the issue 😄

[liquidev]

This seems like a nimterop bug, I'll try to reproduce this and talk about this to @genotrance.

Meanwhile, make sure that you're running latest nimterop and regex, they have caused some problems for me on devel.

(oops, closed accidentally)

[liquidev]

Unfortunately nimterop does not have ARC support yet, you'll have to use a different GC for the time being.

[Wazubaba]

Alright. Thanks for checking into this. Here's hoping they can get that fixed up soon!

[genotrance]

This isn't a nimterop issue. If you compile just src/euwren/private/wren.nim with --gc:arc, it builds fine. If you add a cDebug() and write the wrapper to a file and compile that output (eliminating nimterop beyond that point), that works too. If you import this static wrapper and compile euwren.nim, it fails as described in this issue.

There's something in euwren.nim that is breaking with arc but it is totally unclear which specific line is causing this. There is no hint for what the issue is. Here's the stack trace from koch temp. Hopefully, @Araq has some ideas.

/home/dir/nimdevel/compiler/nim.nim(118) nim
/home/dir/nimdevel/compiler/nim.nim(95) handleCmdLine
/home/dir/nimdevel/compiler/cmdlinehelper.nim(77) loadConfigsAndRunMainCommand
/home/dir/nimdevel/compiler/main.nim(190) mainCommand
/home/dir/nimdevel/compiler/main.nim(92) commandCompileToC
/home/dir/nimdevel/compiler/modules.nim(143) compileProject
/home/dir/nimdevel/compiler/modules.nim(84) compileModule
/home/dir/nimdevel/compiler/passes.nim(216) processModule
/home/dir/nimdevel/compiler/passes.nim(86) processTopLevelStmt
/home/dir/nimdevel/compiler/sem.nim(604) myProcess
/home/dir/nimdevel/compiler/sem.nim(572) semStmtAndGenerateGenerics
/home/dir/nimdevel/compiler/semstmts.nim(2303) semStmt
/home/dir/nimdevel/compiler/semexprs.nim(1006) semExprNoType
/home/dir/nimdevel/compiler/semexprs.nim(2801) semExpr
/home/dir/nimdevel/compiler/importer.nim(218) evalImport
/home/dir/nimdevel/compiler/importer.nim(188) impMod
/home/dir/nimdevel/compiler/importer.nim(158) myImportModule
/home/dir/nimdevel/compiler/modules.nim(98) importModule
/home/dir/nimdevel/compiler/modules.nim(84) compileModule
/home/dir/nimdevel/compiler/passes.nim(216) processModule
/home/dir/nimdevel/compiler/passes.nim(86) processTopLevelStmt
/home/dir/nimdevel/compiler/sem.nim(604) myProcess
/home/dir/nimdevel/compiler/sem.nim(572) semStmtAndGenerateGenerics
/home/dir/nimdevel/compiler/semstmts.nim(2303) semStmt
/home/dir/nimdevel/compiler/semexprs.nim(1006) semExprNoType
/home/dir/nimdevel/compiler/semexprs.nim(2786) semExpr
/home/dir/nimdevel/compiler/semstmts.nim(2082) semProc
/home/dir/nimdevel/compiler/semstmts.nim(2001) semProcAux
/home/dir/nimdevel/compiler/semexprs.nim(1764) semProcBody
/home/dir/nimdevel/compiler/semexprs.nim(2768) semExpr
/home/dir/nimdevel/compiler/semstmts.nim(2243) semStmtList
/home/dir/nimdevel/compiler/semexprs.nim(2679) semExpr
/home/dir/nimdevel/compiler/semexprs.nim(2271) semMagic
/home/dir/nimdevel/compiler/semexprs.nim(988) semDirectOp
/home/dir/nimdevel/compiler/semexprs.nim(888) afterCallActions
/home/dir/nimdevel/compiler/ast.nim(1100) magicsAfterOverloadResolution
/home/dir/nimdevel/lib/system/fatal.nim(49) sysFatal
Error: unhandled exception: 'sym' is not accessible using discriminant 'kind' of type 'TNode' [FieldError]
FAILURE

[liquidev]

@genotrance, right. I already encountered at least two more issues where euwren triggered some edge case in the compiler in the past, I may be able to debug this myself somehow.

Unfortunately I wasn't able to report them properly since I wasn't able to reproduce them in a minimal example.