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

Problem with the same name for module and exported type #3333

Closed
vegansk opened this issue Sep 16, 2015 · 5 comments

Comments

@vegansk
Copy link
Contributor

commented Sep 16, 2015

Test case. We have twop files. First called List.nim:

{.experimental.}

type
  ListNodeKind = enum 
    lnkNil, lnkCons
  List*[T] = ref object
    ## List ADT
    case kind: ListNodeKind
    of lnkNil:
      discard
    of lnkCons:
      value: T
      next: List[T] not nil

The second file:

import List

type
  OptionKind = enum
    okNone, okSome
  Option[T] = ref object
    case kind: OptionKind
    of okNone:
      discard
    else:
      value: T

# This line compiles
proc test1[T: SomeNumber](xs: List[T]): List[T] = discard
# And this line fails
proc test2[T: SomeNumber](xs: List[T]): Option[List[T]] = discard

The return value of proc test1 doesn't bother the compiler. But it fails on proc test2 with the message:

Error: expression 'List' has no type (or is ambiguous)

If you rename List.nim to list.nim and fix the import, the error dissapears.

@vegansk

This comment has been minimized.

Copy link
Contributor Author

commented Sep 21, 2015

And another problem. When the module is imported like this:

from List import List

, the compiler fails with the stacktrace:

Error: internal error: importSymbol: 2
Traceback (most recent call last)
nim.nim(104)             nim
nim.nim(68)              handleCmdLine
main.nim(251)            mainCommand
main.nim(63)             commandCompileToC
modules.nim(214)         compileProject
modules.nim(162)         compileModule
passes.nim(203)          processModule
passes.nim(137)          processTopLevelStmt
sem.nim(458)             myProcess
sem.nim(432)             semStmtAndGenerateGenerics
semstmts.nim(1475)       semStmt
semexprs.nim(910)        semExprNoType
semexprs.nim(2307)       semExpr
importer.nim(171)        evalImport
importer.nim(161)        myImportModule
modules.nim(175)         importModule
modules.nim(162)         compileModule
passes.nim(203)          processModule
passes.nim(137)          processTopLevelStmt
sem.nim(458)             myProcess
sem.nim(432)             semStmtAndGenerateGenerics
semstmts.nim(1475)       semStmt
semexprs.nim(910)        semExprNoType
semexprs.nim(2313)       semExpr
importer.nim(187)        evalFrom
importer.nim(103)        importSymbol
msgs.nim(963)            internalError
msgs.nim(937)            liMessage
msgs.nim(802)            handleError
FAILURE
@narimiran

This comment has been minimized.

Copy link
Member

commented Oct 9, 2018

The first example works fine in Nim v0.19.0.

from List import List

This still fails with: Error: internal error: importSymbol: 2

@disruptek

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

If the compiler cannot be fixed to compile the code, perhaps it could fail with a better error message? Versions of this defect have existed since at least 2013!

@Araq

This comment has been minimized.

Copy link
Member

commented Apr 9, 2019

Sure, yes, I'm sorry.

@Araq Araq added the High Priority label May 28, 2019

@c-blake

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

This may well be related to #11052 where the difference is proc symbols instead of type symbols (though it could also be at a different phase/pass of compiler analysis).

@Araq Araq closed this in cab0c3e Jul 6, 2019

narimiran added a commit that referenced this issue Jul 8, 2019

fixes #3333
(cherry picked from commit cab0c3e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.