Nim icon indicating copy to clipboard operation
Nim copied to clipboard

Proc argument type derived from expression with generic type argument causes segfault in compiler

Open cmd410 opened this issue 3 years ago • 0 comments

Proc argument type derived from generic type argument causes segfault in compiler.

Example

The following code results in compiler segfault:

type Test[S: static[Natural]] = object
  
proc run(self: Test, idx: 0..(self.S * 8)) = discard
#       This causes segfault ^^^^^^^^^^^^
proc run(self: Test, a: array[self.S * 8, int]) = discard
#                And this too ^^^^^^^^^^

Any other static value or absense of operator does not cause the problem, for example

type Test[S: static[Natural]] = object
  
const a = 32

proc run(self: Test, idx: 0..(a * 8)) = discard  # compiles as expected
proc run(self: Test, idx: 0..self.S) = discard  # compiles as expected
proc run(self: Test, a: array[self.S, int]) = discard  # compiles as expected

Current Output

.\Nim\bin\nim c test.nim
Hint: used config file '...\Nim\config\nim.cfg' [Conf]
Hint: used config file '...\Nim\config\config.nims' [Conf]
.........................................................Traceback (most recent call last)
...\Nim\compiler\nim.nim(138) nim
...\Nim\compiler\nim.nim(94) handleCmdLine
...\Nim\compiler\main.nim(278) mainCommand
...\Nim\compiler\main.nim(248) compileToBackend
...\Nim\compiler\main.nim(104) commandCompileToC
...\Nim\compiler\modules.nim(178) compileProject
...\Nim\compiler\modules.nim(98) compileModule
...\Nim\compiler\passes.nim(186) processModule
...\Nim\compiler\passes.nim(74) processTopLevelStmt
...\Nim\compiler\sem.nim(653) myProcess
...\Nim\compiler\sem.nim(621) semStmtAndGenerateGenerics
...\Nim\compiler\semstmts.nim(2367) semStmt
...\Nim\compiler\semexprs.nim(1066) semExprNoType
...\Nim\compiler\semexprs.nim(3007) semExpr
...\Nim\compiler\semstmts.nim(2309) semStmtList
...\Nim\compiler\semexprs.nim(2902) semExpr
...\Nim\compiler\semexprs.nim(1047) semDirectOp
...\Nim\compiler\semexprs.nim(878) semOverloadedCallAnalyseEffects
...\Nim\compiler\semcall.nim(588) semOverloadedCall
...\Nim\compiler\semcall.nim(371) resolveOverloads
...\Nim\compiler\semcall.nim(95) pickBestCandidate
...\Nim\compiler\sigmatch.nim(2551) matches
...\Nim\compiler\sigmatch.nim(2485) matchesAux
...\Nim\compiler\sigmatch.nim(2192) paramTypesMatch
...\Nim\compiler\sigmatch.nim(2086) paramTypesMatchAux
...\Nim\compiler\sigmatch.nim(1873) implicitConv
...\Nim\compiler\sigmatch.nim(1863) getInstantiatedType
...\Nim\compiler\semtypinst.nim(701) generateTypeInstance
...\Nim\compiler\semtypinst.nim(118) replaceTypeVarsT
...\Nim\compiler\semtypinst.nim(614) replaceTypeVarsTAux
...\Nim\compiler\semtypinst.nim(241) replaceTypeVarsN
...\Nim\compiler\semtypinst.nim(230) replaceTypeVarsN
...\Nim\compiler\semtypinst.nim(133) prepareNode
...\Nim\compiler\semtypinst.nim(122) prepareNode
...\Nim\compiler\semtypinst.nim(118) replaceTypeVarsT
...\Nim\compiler\semtypinst.nim(540) replaceTypeVarsTAux
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

The last traceback line refers here:

https://github.com/nim-lang/Nim/blob/6f290fa3863824ec935d381bfefc850acd75196f/compiler/semtypinst.nim#L540

Expected Output

Should compile, or at the very least not cause compiler segfault.

Possible Solution

No idea, but it appears that t.n is nil in replaceTypeVarsTAux

Additional Information

$ .\Nim\bin\nim -v
Nim Compiler Version 1.6.7 [Windows: amd64]       
Compiled at 2022-06-23
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 6f290fa3863824ec935d381bfefc850acd75196f
active boot switches:

cmd410 avatar Jun 23 '22 08:06 cmd410