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

Identifier exported as typename in one module and template in another can't be used in template #23898

Closed
tersec opened this issue Jul 27, 2024 · 0 comments · Fixed by #23997
Closed

Comments

@tersec
Copy link
Contributor

tersec commented Jul 27, 2024

Description

c.nim:

type K* = object

s.nim:

import ./c
export c
template K*(kind: static int): auto = typedesc[c.K]
template B*(kind: static int): auto = typedesc[c.K]

j.nim

import ./s
discard default(B(0))       # compiles
discard default(s.B(0))     # compiles
discard default(K(0))       # compiles
template r() =
  discard default(B(0))     # compiles
  discard default(s.B(0))   # compiles
  discard default(K(0))     # does not compile

Nim Version

Nim Compiler Version 2.0.10 [Linux: amd64]
Compiled at 2024-07-27
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 92e505577e8b6b9214b6fcdd7fe1b0e9a244023b
active boot switches: -d:release
Nim Compiler Version 2.1.9 [Linux: amd64]
Compiled at 2024-07-27
Copyright (c) 2006-2024 by Andreas Rumpf

git hash: 39629a1adcbcc822508acc3983f444328f90dd85
active boot switches: -d:release

Current Output

j.nim(8, 19) Error: ambiguous identifier: 'K' -- use one of the following:
  c.K: K
  s.K: template (kind: static[int]): auto

Expected Output

If B(0), s.B(0), and K(0) work outside the template, and B(0) and s.B(0) work inside the template, K(0) also works inside the template.

Possible Solution

No response

Additional Information

Related to #23893 and c.nim and s.nim in both issues are identical.

In particular, as a result of that issue, one cannot work around this issue that readily in templates because by adding that disambiguating module identifier, it hits that issue instead of this issue but still does not compile.

metagn added a commit to metagn/Nim that referenced this issue Aug 20, 2024
metagn added a commit to metagn/Nim that referenced this issue Aug 20, 2024
metagn added a commit to metagn/Nim that referenced this issue Aug 21, 2024
metagn added a commit to metagn/Nim that referenced this issue Aug 21, 2024
@Araq Araq closed this as completed in 09dcff7 Aug 25, 2024
narimiran pushed a commit that referenced this issue Sep 16, 2024
…le types in symchoices (#23997)

fixes #23898, supersedes #23966 and #23990

Since #20631 ambiguous type symbols in templates are rejected outright,
now we generate a symchoice for type nodes if they're ambiguous, a
generalization of what was done in #22375. This is done for generics as
well. Symchoices also handle type symbols better now, ensuring their
type is a `typedesc` type; this probably isn't necessary for everything
to work but it makes the logic more robust.

Similar to #23989, we have to prepare for the fact that ambiguous type
symbols behave differently than normal type symbols and either error
normally or relegate to other routine symbols if the symbol is being
called. Generating a symchoice emulates this behavior, `semExpr` will
find the type symbol first, but since the symchoice has other symbols,
it will count as an ambiguous type symbol.

I know it seems spammy to carry around an ambiguity flag everywhere, but
in the future when we have something like #23104 we could just always
generate a symchoice, and the symchoice itself would carry the info of
whether the first symbol was ambiguous. But this could harm compiler
performance/memory use, it might be better to generate it only when we
have to, which in the case of type symbols is only when they're
ambiguous.

(cherry picked from commit 09dcff7)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants