Nim icon indicating copy to clipboard operation
Nim copied to clipboard

importc types (eg cint) don't alias properly, causing codegen errors

Open timotheecour opened this issue 6 years ago • 3 comments

importc types (eg cint) don't alias properly, causing codegen errors. The bug affects not just tuples, but also seq and generics, see example below.

Example 1: tuple

  type cdouble2 = cdouble
  static: doAssert (cdouble2,) is (cdouble,)
  var a1: cdouble
  var a2: cdouble2
  echo (a1,) # bug
  echo (a2,)
  # echo (f0:a1) # ditto
  # echo (f0:a2)

gives:

  error: passing 'tyTuple_Hgvfzc2J6wQcFj9cZDv3TzA' (aka 'strucThis is the root cause for a number of other issues, eg:
* https://github.com/nim-lang/Nim/issues/10272 is actually caused by this, the `template` aspect was a red herring as I can reproduce without using a template, see example 1 below; I'm closing it in favor of this issue to regroup all such errors
* https://github.com/nim-lang/Nim/issues/5905 same root cause as this issue IMO
* https://github.com/nim-lang/Nim/issues/7308 ditto

t tyTuple_Hgvfzc2J6wQcFj9cZDv3TzA') to parameter of incompatible type 'tyTuple_49cnoQKEYR9ajF4huQ9axkrPA' (aka 'struct tyTuple_49cnoQKEYR9ajF4huQ9axkrPA')

Example 2: seq

  type cdouble2 = cdouble
  type Foo1 = seq[cdouble]
  type Foo2 = seq[cdouble2]
  static: doAssert Foo1 is Foo2
  var a1: Foo1
  var a2: Foo2
  echo a1
  echo a2

gives:

with nim c + applying my PR https://github.com/nim-lang/Nim/pull/11591 to show warnings:

    warning: incompatible pointer types passing 'tySequence_SzjWP9aHgRAne4ZmmpQJswA *' (

with nim cpp:

    error: no matching function for call to 'dollar__mQi9aw8yQo9aUaY1UeCrqGZw'

Example 3: generic

when defined case3:
  proc foo*[T: int|cint](fun: proc(): T) = discard
  proc foo1(): cint = 1
  proc foo3(): int32 = 2
  foo(proc(): cint = foo1())
  foo(proc(): int32 = foo3())

gives:

  error: passing 'tyProc_mO8Oq7pOVoUIjl3l7pqNbQ' to parameter of incompatible type 'tyProc_9cre9aMyMjDQAORxsXaz9coyQ'

Expected Output

should compile

Possible Solution

the issues go away if we replace

  cint* {.importc: "int", nodecl.} = int32 ## This is the same as the type ``int`` in *C*.

by

type cint* = int32

as suggested in https://github.com/nim-lang/Nim/issues/5905#issuecomment-323692233 ; a temporary fix would involve fixing all other similar type definitions via importc, but maybe a proper fix would involve fixing codegen for importc types

Additional Information

D20190410T175427

  • Your Nim version (output of nim -v). latest devel f50e4500c257e3d57654f5230db75042da233d24

  • Was it working in the previous Nim releases? no

This is the root cause for a number of other issues, eg:

  • https://github.com/nim-lang/Nim/issues/10272 is actually caused by this, the template aspect was a red herring as I can reproduce without using a template, see example 1 below; I'm closing it in favor of this issue to regroup all such errors
  • https://github.com/nim-lang/Nim/issues/5905 same root cause as this issue IMO
  • https://github.com/nim-lang/Nim/issues/7308 ditto

timotheecour avatar Jul 20 '19 05:07 timotheecour