I am starting to lose track of all bug reports linked to generics and static early symbol resolution.

Context

Quoting @Araq

The pre-instantiation lookup is required to implement the proper "open vs closed symbol lookup" rules.

http://nim-lang.org/docs/manual.html#generics-symbol-lookup-in-generics

It's a tough issue, maybe we need to weaken the prepass if a 'this' parameter is used.

Impact

• .this pragma doesn't work with generics #5053: .this pragma doesn't work with generics
• generic object with generic field evaluated too early #5540: generic object with generic field evaluated too early
• List comprehensions do not work with generic parameter #5707: List comprehensions do not work with generic parameter (needs mixin)
• Generics proc + macros: identifier resolution happens before macros #6387: Generics proc + macros: identifier resolution happens before macros
• mixin + block expression: works in Generics, not in "normal" proc #7385: mixin + block expression: works in Generics, not in "normal" proc
• {.this: self.} does not work with Static[T] #7618: {.this: self.} does not work with Static[T]
• strformat doesn't work properly inside generics #7632: strformat doesn't work properly inside generics and templates
• when in generic should fail earlier #8603: when should check the code at the same depth like if
• Usability: {.experimental: “ForLoopMacros”.} is required at all macro callsites #8676: Usability: {.experimental: “ForLoopMacros”.} is required at all macro callsites
• Documentation with when branch is missing field types #9899: Documentation with when branch is missing field types
• The async pragma doesn't work properly with a nested proc inside a generic function #10818: The async pragma doesn't work properly with a nested proc inside a generic function
• untyped macro nested in template: getting sym instead of idents #11091: [template] untyped macro nested in template: getting sym instead of idents
• Invoking generic procedure that uses varargs implicit conversion acts incorrectly #11154: Invoking generic procedure that uses varargs implicit conversion acts incorrectly
• for loop invoked from generic procedure defined in another module cant find items iterator #11167: Template with for loop invoked from generic procedure defined in another module cant find items iterator
• symbol resolution issues when ambiguous call happens in generic proc #11188: symbol resolution issues when ambiguous call happens in generic proc
• Generics "sandwiched" between two modules don't mixin their scope symbols properly #11225: Generics "sandwiched" between two modules don't mixin their scope symbols properly

Solution

Most advanced discussion is in #8603
Quoting @zah

Er, it's a bug and a rather simple one. The generic pre-pass in semgnrc.nim have to examine the when condition expressions in the same way it examines all other expressions.

The fix I imagine is that you should just call semGenericStmt on the when condition expression (n.sons[0])

I'll have to look at some specific examples. Inside the compiler, we keep track of which generic symbols are in "unresolved" state and we need to add guards in the code detecting such symbols in many places. I suspect something similar is going on here as well.