Different symbol resolution in generic types depending on f(x) vs f x call syntax

[SirNickolas]

Description

When a generic type is defined as a routine invocation, it—surprisingly—matters whether the call has parentheses or not.

template helper(_: untyped): untyped =
  int

type # Each of them should always be `int`.
  GenA[T] = helper int
  GenB[T] = helper(int)
  GenC[T] = helper helper(int)

block:
  template helper(_: untyped): untyped =
    float

  type
    A = GenA[int]
    B = GenB[int]
    C = GenC[int]

  assert A is int # OK.
  assert B is int # Fails; it is `float`!
  assert C is int # OK.

Nim Version

Nim Compiler Version 2.0.2 [Linux: amd64]
Compiled at 2023-12-15
Copyright (c) 2006-2023 by Andreas Rumpf

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

Current Output

Error: unhandled exception: /home/nickolas/c/asynciters/a.nim(19, 3) `B is int`  [AssertionDefect]

Expected Output

No response

Possible Solution

No response

Additional Information

It seems to be irrelevant whether helper has untyped, typed, or type parameter / return value. As I see, the only thing that matters is whether the command-call syntax is used for the top-level call.

This bug has been existing since at least 0.19—that’s the oldest Nim I have on my system to check.

[metagn]

Culprit is probably:

Nim/compiler/semtypes.nim

Line 2028 in c2c0077

if c.inGenericContext > 0 and n.kind == nkCall:

Should be n.kind in nkCallKinds, but apparently this was intentional at the time this line was added. Maybe things are different now though. Worst case we just whitelist nkCommand too.