Imports don't resolve correctly when generics are involved.

[distantforest1]

Description

It appears that nim doesn't resolve the imports correctly when generics are involved.

For example I have two files

• main.nim
• grouptest.nim

main.nim

import grouptest
# import sets # <<-- Uncomment this to make the error go away

## The generic implementation
var grp: EntGroup[Fruit] = initEntGroup[Fruit]()
echo get(grp) ## Errors here


## This works though (Non-generic)
var fruitGroup: FruitGroup = initFruitGroup()
echo getNoGeneric(fruitGroup)

grouptest.nim

import sets, hashes

type
  Fruit* = ref object
    id*: int

  # Generic implementation. This doesn't work
  EntGroup*[T] = ref object
    freed*: HashSet[T]

proc hash*(self: Fruit): Hash = hash(self.id)

##
## VVV The Generic implementation. This doesn't work VVV
##

proc initEntGroup*[T: Fruit](): EntGroup[T] =
  result = EntGroup[T]()
  result.freed = initHashSet[Fruit]()
  var apple = Fruit(id: 20)
  result.freed.incl(apple)

proc get*[T: Fruit](fg: EntGroup[T]): T =
  if len(fg.freed) == 0: return
  # vvv It errors here 
  # type mismatch: ([1] fg.freed: HashSet[grouptest.Fruit])
  for it in fg.freed: 
    return it

##
## VVV The Non-Generic implementation works VVV
##
type
  # Non-generic implementation. This works.
  FruitGroup* = ref object
    freed*: HashSet[Fruit]

proc initFruitGroup*(): FruitGroup =
  result = FruitGroup()
  result.freed = initHashSet[Fruit]()
  var apple = Fruit(id: 20)
  result.freed.incl(apple)

proc getNoGeneric*(fg: FruitGroup): Fruit =
  if len(fg.freed) == 0: return
  for it in fg.freed:
    return it

proc `$`*(self: Fruit): string = 
  # For echo
  if self == nil: return "Fruit()"
  return "Fruit(" & $(self.id) & ")"

Adding the import sets within the main.nim makes the error go away. So it seems that it is creating the get() proc within main.nim, rather than in grouptest.nim. If this is true, this might create some unforeseen for things such as libraries or 3rd party code.

I have the files zipped up here to make it easier to test
importbug.zip

Nim Version

Nim Compiler Version 2.0.0 [Windows: amd64]
Compiled at 2023-08-01
Copyright (c) 2006-2023 by Andreas Rumpf

active boot switches: -d:release

Current Output

D:\Code\nim\raylib\samples\bugs\importbug\grouptest.nim(14, 15) Error: type mismatch
Expression: items(fg.freed)
  [1] fg.freed: HashSet[grouptest.Fruit]

Expected one of (first mismatch at [position]):
[1] iterator items(a: cstring): char
[1] iterator items(a: string): char
[1] iterator items[IX, T](a: array[IX, T]): T
[1] iterator items[T: Ordinal](s: Slice[T]): T
[1] iterator items[T: char](a: openArray[T]): T
[1] iterator items[T: enum and Ordinal](E: typedesc[T]): T
[1] iterator items[T: not char](a: openArray[T]): lent2 T
[1] iterator items[T](a: seq[T]): lent2 T
[1] iterator items[T](a: set[T]): T

Expected Output

No error

Possible Solution

Not exactly sure what is causing the issue, but as mentioned earlier it seems that it's creating the get() proc within main.nim, rather than in grouptest.nim. It would be best to create the proc at its original location rather than when it was first called (in this case it was called in main.nim)
.

Additional Information

No response

[beef331]

Implicit items is broken inside generics do for a in b.items for a workaround.

[distantforest1]

ok thanks

[mratsim]

Another case of generic sandwiches:

• Generics "sandwiched" between two modules don't mixin their scope symbols properly #11225
• Concepts and cross-module generic binding madness #16755

[beef331]

This is actually not a generic sandwich issue, it's just implicit items being broken with generics. Due to how implicit iterators are resolved it never looks up the bounded symbols. So even a mixin items does not resolve the issue with it.