Giters

nim-lang / Nim

Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

Home Page:https://nim-lang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

regression from 1.6/2.0.4 to `version-2-0`/`devel` instantiating nested generic objects generic function

tersec opened this issue · comments

commented

Description

type G[T] = object
  j: T
proc s[T](u: int) = discard
proc s[T]() = discard
proc c(e: int | int): G[G[G[int]]] = s[G[G[int]]]()
discard c(0)

Nim Version

Builds:

Nim Compiler Version 1.6.21 [Linux: amd64]
Compiled at 2024-05-04
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 6a63df181f71635538dd29aed0365b663800016e
active boot switches: -d:release

Nim Compiler Version 2.0.4 [Linux: amd64]
Compiled at 2024-05-04
Copyright (c) 2006-2023 by Andreas Rumpf

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

Does not bulid:

Nim Compiler Version 2.0.5 [Linux: amd64]
Compiled at 2024-05-04
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 526e48b2ed2ee3e9dad9d61c1f3a96444225ebc4
active boot switches: -d:release

Nim Compiler Version 2.1.1 [Linux: amd64]
Compiled at 2024-05-04
Copyright (c) 2006-2024 by Andreas Rumpf

git hash: 1ef4d04a1e56f67d85559a7964e9467df06bc2d7
active boot switches: -d:release

Current Output

/root/v.nim(6, 10) template/generic instantiation of `c` from here
/root/v.nim(5, 41) Error: cannot instantiate G [type declared in /root/v.nim(1, 6)]
got: <T>
but expected: <T>

Expected Output

2.0.5 and devel also build this

Possible Solution

No response

Additional Information

No response

commented

Bisecting on version-2-0 branch says it is this commit: d436728, which was recently backported.

For 2.0.x, we can revert the backport, but ideally: we would have a proper fix in devel, which then I can backport.

cc @metagn @arnetheduck

commented

Should be the same issue as #23310, I just realized what the issue is, semtypes calls semGenericStmt in type sections which does the genericsOpenSym behavior which it shouldn't do, we should probably only enable it for the first pass of generic procs by a flag through semGenericStmt into GenericsCtx, should be easy

commented

I was wrong, the culprit is this diff: d436728#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40R1028-R1031

Reverting these lines fixes the 2.0 branch but breaks devel, I'll look into fixing devel with it