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

Regression from 1.6 to 2.0 and devel with generics across modules #22373

Closed
tersec opened this issue Aug 3, 2023 · 1 comment · Fixed by #22375
Closed

Regression from 1.6 to 2.0 and devel with generics across modules #22373

tersec opened this issue Aug 3, 2023 · 1 comment · Fixed by #22375

Comments

@tersec
Copy link
Contributor

tersec commented Aug 3, 2023

Description

Current approach requires three modules to reproduce -- it seems to relate to the import structure (A imports C, then A imports B which imports C). This probably isn't 100% required, but there are no other external imports required, stdlib or otherwise.

# Order matters to reproduce this; switch these and it builds
import ./altair
import ./forks_light_client

template lazy_header(name: untyped): untyped {.dirty.} =
  var `name _ ptr`: ptr[data_fork.LightClientHeader]  # this data_fork.Foo part seems required to reproduce

proc createLightClientUpdates(data_fork: static LightClientDataFork) =
  lazy_header(attested_header)

createLightClientUpdates(LightClientDataFork.Altair)

Where altair.nim:

type
  LightClientHeader* = object

and forks_light_client.nim:

import ./altair

type
  LightClientDataFork* {.pure.} = enum
    None = 0,
    Altair = 1

template LightClientHeader*(kind: static LightClientDataFork): auto =
  when kind == LightClientDataFork.Altair:
    typedesc[altair.LightClientHeader]
  else:
    static: raiseAssert "Unreachable"

A number of interesting quirks here, e.g., without the `{.dirty.} it fails with

a.nim(6, 35) Error: ambiguous identifier: 'LightClientHeader' -- use one of the following:
  altair.LightClientHeader: LightClientHeader
  forks_light_client.LightClientHeader: template (kind: static[LightClientDataFork]): auto

regardless of Nim 1.6/2.0/devel

Nim Version

Nim Compiler Version 1.6.14 [Linux: amd64]
Compiled at 2023-06-29
Copyright (c) 2006-2023 by Andreas Rumpf

active boot switches: -d:release
Nim Compiler Version 2.0.0 [Linux: amd64]
Compiled at 2023-08-03
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: a488067a4130f029000be4550a0fb1b39e0e9e7c
active boot switches: -d:release
Nim Compiler Version 2.1.1 [Linux: amd64]
Compiled at 2023-08-03
Copyright (c) 2006-2023 by Andreas Rumpf

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

Current Output

Nim 1.6 builds successfully.

Nim 2.0/devel:
a.nim(11, 25) template/generic instantiation of `createLightClientUpdates` from here
a.nim(6, 34) Error: type mismatch: got 'LightClientDataFork' for 'LightClientDataFork.Altair' but expected 'LightClientHeader = object'

Expected Output

No response

Possible Solution

No response

Additional Information

No response

@metagn
Copy link
Collaborator

metagn commented Aug 3, 2023

Simplified (generics bug, not related to templates or interpolating symbol names):

# a.nim
type TypeOrTemplate* = object

# b.nim
import a

template TypeOrTemplate*(num: int): untyped =
  # module a only exists so we can pick the type version of TypeOrTemplate here
  typedesc[a.TypeOrTemplate]

# c.nim
import a, b

proc generic[T](abc: T) =
  var x: abc.TypeOrTemplate

generic(123)

Caused by #21837

metagn added a commit to metagn/Nim that referenced this issue Aug 3, 2023
@tersec tersec changed the title Regression from 1.6 to 2.0 and devel with template interpolating symbol names Regression from 1.6 to 2.0 and devel with generics across modules Aug 3, 2023
narimiran pushed a commit that referenced this issue Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants