SIGSEGV when return type depends on a `static[T]` parameter

[timotheecour]

BUG: case2 below should work, but it gives SIGSEGV

template bar(a: static[bool]): untyped = int

when defined(case1):
  # ok
  proc foo(a: static[bool]): auto = 1

when defined(case2):
  # SIGSEGV: see stacktrace in [1]
  proc foo(a: static[bool]): bar(a) = 1

when defined(case3):
  # Error: type mismatch: got <bool> but expected ... static[bool]
  proc foo(a: static[bool]): bar(static[bool](a)) = 1

when defined(case4):
  # Error: expression cannot be cast to static[bool]
  proc foo(a: static[bool]): bar(cast[static[bool]](a)) = 1

echo foo(true)

#[
[1]
/Users/timothee/git_clone/nim/Nim/compiler/nim.nim(133) nim
/Users/timothee/git_clone/nim/Nim/compiler/nim.nim(97) handleCmdLine
/Users/timothee/git_clone/nim/Nim/compiler/main.nim(162) mainCommand
/Users/timothee/git_clone/nim/Nim/compiler/main.nim(73) commandCompileToC
/Users/timothee/git_clone/nim/Nim/compiler/modules.nim(124) compileProject
/Users/timothee/git_clone/nim/Nim/compiler/modules.nim(71) compileModule
/Users/timothee/git_clone/nim/Nim/compiler/passes.nim(194) processModule
/Users/timothee/git_clone/nim/Nim/compiler/passes.nim(103) processTopLevelStmt
/Users/timothee/git_clone/nim/Nim/compiler/sem.nim(592) myProcess
/Users/timothee/git_clone/nim/Nim/compiler/sem.nim(560) semStmtAndGenerateGenerics
/Users/timothee/git_clone/nim/Nim/compiler/semstmts.nim(1891) semStmt
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(912) semExprNoType
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(2444) semExpr
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(2050) semWhen
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(2520) semExpr
/Users/timothee/git_clone/nim/Nim/compiler/semstmts.nim(1832) semStmtList
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(2538) semExpr
/Users/timothee/git_clone/nim/Nim/compiler/semstmts.nim(1682) semProc
/Users/timothee/git_clone/nim/Nim/compiler/semstmts.nim(1508) semProcAux
/Users/timothee/git_clone/nim/Nim/compiler/semstmts.nim(1119) semParamList
/Users/timothee/git_clone/nim/Nim/compiler/semtypes.nim(1110) semProcTypeNode
/Users/timothee/git_clone/nim/Nim/compiler/semtypes.nim(1492) semTypeNode
/Users/timothee/git_clone/nim/Nim/compiler/semtypes.nim(1276) semTypeExpr
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(59) semExprWithType
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(2413) semExpr
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(893) semDirectOp
/Users/timothee/git_clone/nim/Nim/compiler/semexprs.nim(745) semOverloadedCallAnalyseEffects
/Users/timothee/git_clone/nim/Nim/compiler/semcall.nim(467) semOverloadedCall
/Users/timothee/git_clone/nim/Nim/compiler/semcall.nim(435) semResolvedCall
/Users/timothee/git_clone/nim/Nim/compiler/ast.nim(1037) add
/Users/timothee/git_clone/nim/Nim/lib/system.nim(3753) failedAssertImpl
/Users/timothee/git_clone/nim/Nim/lib/system.nim(3746) raiseAssert
/Users/timothee/git_clone/nim/Nim/lib/system.nim(2807) sysFatal
Error: unhandled exception:
not (son == nil)  [AssertionError]

 ]#

NOTE: use case reduced from #8531 (comment)

[mratsim]

The SIGSEGV crash is a regression due to the not nil changes.

On 0.18.0 the output is:

template bar(a: static[bool]): untyped = int
proc foo(a: static[bool]): bar(a) = 1
echo foo(true)

# static.nim(3, 31) Error: type mismatch: got <static[bool]>
# but expected one of:
# template bar(a: static[bool]): untyped
# 
# expression: bar(a)

which is another issue which maybe should be tracked separately? (this one for the not nil regression, another one for passing static for result types).

This reminds me of #7719 / nim-lang/RFCs#44, except for static types instead of generics.

Note that I can also reproduce this with static[int], this is important as static[bool] (and static[enum]) can get silently converted to int at compile time #7375

I think the issue on stable was fixed already by the flurry of static[int] fixes and there is no need to log it. (On stable this fails with the same error but compiles properly on devel)

[timotheecour]

@mratsim just curious: what's the policy on logging and fixing bugs in stable? IMO, given scarce resources, shouldn't we just focus on logging / fixing bugs in devel? (maybe at exception of critical security bugs, idk)

I think the issue on stable was fixed already by the flurry of static[int] fixes and there is no need to log it.

what do you mean by that?
last commit on stable (aka master) is 855956b on 2018-03-01 21:39

[mratsim]

Sorry I was completely unclear.

Regarding the following snippet:

template bar(a: static[bool]): untyped = int
proc foo(a: static[bool]): bar(a) = 1
echo foo(true)

1. On 0.18.0, it throws:

# static.nim(3, 31) Error: type mismatch: got <static[bool]>
# but expected one of:
# template bar(a: static[bool]): untyped
# 
# expression: bar(a)

2. After Static[T] fixes #7333 / 121b9e2 I'm pretty sure it would work

3. After what I suppose all the not nil commits from April 27 to April 30: https://github.com/nim-lang/Nim/commits/599b5d6dcbd8b73d98d1aaf2de94d3360229a699?after=599b5d6dcbd8b73d98d1aaf2de94d3360229a699+34, your regression was introduced.

It reminds me of #7730 and #7746 where less traveled compiler codepaths crashed with SIGSEGV due to the new not nil (compiling with linedir or debugger-native).

---

Regarding bugs in stable, the solution is just to release either 0.x.2 or 0.x+1.0 depending on the changes.

[konsumlamm]

Update:
On latest devel, cases 1, 2 and 4 now work (all print 1), case 3 still gives the same error message, but that seems to be expected (case 4 could be used as a workaround). So I think this issue can be closed (specially since it doesn't SIGSEGV anymore, if case 3 is an issue, that should go into a new issue imo).

$ nim -v
Nim Compiler Version 1.5.1 [Linux: amd64]
Compiled at 2021-03-18
Copyright (c) 2006-2021 by Andreas Rumpf

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

[timotheecour]

also, this works too:

when defined(case5):
  proc foo(a: static[bool]): bar(static(a)) = 1

before closing, we need a test case with case1,2,4,5 (can be simply tests/misc/t8545.nim)
if you volunteer a PR, I can review it fast