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

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

Open
SirNickolas opened this issue Mar 14, 2024 · 1 comment · May be fixed by #23411
Open

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

SirNickolas opened this issue Mar 14, 2024 · 1 comment · May be fixed by #23411

Comments

@SirNickolas
Copy link
Contributor

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
Copy link
Collaborator

metagn commented Mar 15, 2024

Culprit is probably:

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.

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.

2 participants