-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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
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
Description
c.nim
:s.nim
:j.nim
Nim Version
Current Output
Expected Output
Possible Solution
No response
Additional Information
Related to #23893 and
c.nim
ands.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.
The text was updated successfully, but these errors were encountered: