sem: compiler crash on nested routine with `typedesc` parameter within generic parent

[Luyten-Orion]

Specification

Defining a nested template or procedure that accepts a typedesc (not typedesc[T] where T is a type specifier), inside of a proc that has a generic parameter, triggers Fatal: Internal assert '' failed in semtypes.nim(2291, 15).

Example

proc test[T]() =
  template defaultVal(V: typedesc): V =
    when V is ref:
      new(V)
    else:
      default(V)

test[int]()

Actual Output

Fatal: Internal assert '' failed in semtypes.nim(2291, 15)
nim.nim(0)      nim
nim.nim(0)      handleCmdLine
main.nim(0)     mainCommand
main.nim(0)     compileToBackend
main.nim(0)     commandCompileToC
modules.nim(0)  compileProject
modules.nim(0)  compileModule
passes.nim(0)   processModule
passes.nim(0)   processTopLevelStmt
sem.nim(0)      myProcess
sem.nim(0)      semStmtAndGenerateGenerics
semstmts.nim(0) semStmt
semexprs.nim(0) semExprNoType
semexprs.nim(0) semExpr
semstmts.nim(0) semStmtList
semexprs.nim(0) semExpr
semexprs.nim(0) semIndirectOp
semexprs.nim(0) semDirectOp
semexprs.nim(0) semOverloadedCallAnalyseEffects
semcall.nim(0)  semOverloadedCall
semcall.nim(0)  semResolvedCall
seminst.nim(0)  generateInstance
seminst.nim(0)  instantiateBody
semexprs.nim(0) semProcBody
semexprs.nim(0) semExpr
semstmts.nim(0) semStmtList
semexprs.nim(0) semExpr
semstmts.nim(0) semRoutineDef
semtempl.nim(0) semTemplateDef
semstmts.nim(0) semRoutineParams
semstmts.nim(0) semParamList
semtypes.nim(0) semProcTypeNode
semtypes.nim(0) semTypeNode
msgs.nim(0)     doInternalAssert
msgs.nim(0)     handleReport
msgs.nim(0)     quit

Expected Output

No output.

Possible Solution

Additional Information

References

[saem]

I've updated the title to be a bit more succinct, I've done a minor reduction wrt the outer parent being a nullary generic, but haven't looked further

[zerbina]

Minimal reproducer:

proc generic[]() =
  proc inner(T: typedesc): T =
    discard
generic[]()

This is a non-trivial issue. It has to do with typedesc parameters being treated differently depending on whether in a generic instantiation context (tracked by PContext.inGenericInst) or not (refer to the implementation of semTypeIdent).

inGenericInst shouldn't exist in the first place, and the following is what I'd consider a proper fix:

1. don't create an skParam for static and typedesc parameters; use the symbol of the generated implicit generic parameter instead
2. remove all special handling for typedesc/static skParam symbols from the rest of the compiler

The effect would be that, from the perspective of a symbol usage, there's no more difference between a typedesc generic parameter and a typedesc parameter (same for static). This would be a breaking change, however, because:

• a typedesc parameter is currently a "real" parameter during compile-time execution, which it couldn't continue to be
• parameters have different symbol binding behaviour when compared to generic parameters...