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

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

Open
cmd410 opened this issue Jun 23, 2022 · 0 comments · May be fixed by #24086
Open

Comments

@cmd410
Copy link
Contributor

cmd410 commented Jun 23, 2022

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:

assert t.n.typ != t

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:
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.

1 participant