add a procedure with the same name as a generic template and then calling this generic template from a generic identifier, compilation gives error

[rockcavera]

When a procedure with the same name as a generic template is added and then this generic template is called from a generic identifier, the compilation gives an error.

Example

# myint128.nim
type
  UInt128* = object
    lo, hi: uint64

func `<`*(x, y: UInt128): bool =
  (x.hi < y.hi) or ((x.hi == y.hi) and (x.lo < y.lo))

when not defined(works):
  func `>`*(x, y: UInt128): bool =
    (x.hi > y.hi) or ((x.hi == y.hi) and (x.lo > y.lo))

# bug.nim
import ./myint128

var m: seq[uint64]

proc test[T: uint64|uint32](s: var seq[T]) =
  var tmp = newSeq[T](1)
  s = newSeq[T](1)

  echo s[0] > tmp[0]

test(m)

Current Output

nim c bug
Hint: used config file 'D:\Nim\config\nim.cfg' [Conf]
Hint: used config file 'D:\Nim\config\config.nims' [Conf]
..........................................................
C:\Users\josep\Desktop\bug.nim(11, 5) template/generic instantiation of `test` from here
C:\Users\josep\Desktop\bug.nim(9, 13) Error: type mismatch: got <uint64, T>
but expected one of:
proc `<`(x, y: uint64): bool
  first type mismatch at position: 2
  required type for y: uint64
  but expression 's[0]' is of type: T
21 other mismatching symbols have been suppressed; compile with --showAllMismatches:on to see them

expression: tmp[0] < s[0]

Expected Output

Must compile and when run return false

Additional Information

• The problem is present in version 1.0.0 up to the current devel.
• if compiled with -d:works, compilation proceeds correctly as it is not declared myint128.>

[metagn]

This might be specific to seq and UncheckedArray similar to what was encountered in #23854 and #23855

More isolated test code:

# mseq1.nim
proc foo*(x: int) = discard
template templ*(x: untyped) =
  foo(x)

# mseq2.nim
# string can be any type other than what test receives:
proc templ*(x: string) = discard

import mseq1
import mseq2

proc test[T](s: seq[T]) =
  templ s[0]

test(@[0])

I think it has to do with the use of the subscript operator

Edit: Definitely, the T in the error is the T from the definition of the subscript operator:

proc `[]`*[I: Ordinal;T](a: T; i: I): T {.noSideEffect, magic: "ArrGet".}