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

treat resolved symbols on RHS of module qualification as identifiers #24180

Merged
merged 1 commit into from
Sep 27, 2024

Conversation

metagn
Copy link
Collaborator

@metagn metagn commented Sep 26, 2024

fixes #19866 given #23997

When searching for a module-qualified symbol, qualifiedLookUp tries to obtain the raw identifier from the RHS of the dot field. However it only does this when the RHS is either an nkIdent or an nkAccQuoted node, not when the node is a resolved symbol or a symchoice, such as in templates and generics when the module symbol can't be resolved yet. Since the LHS is a module symbol when the compiler checks for this, any resolved symbol information doesn't matter, since it has to be a member of the module. So we now obtain the identifier from these nodes as well as the unresolved identifier nodes.

The test is a bit niche and possibly not officially supported, but this is likely a more general problem and I just couldn't think of another test that would be more "proper". It's better than the error message 'a' has no type at least.

@Araq Araq merged commit 75b9d66 into nim-lang:devel Sep 27, 2024
19 checks passed
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 75b9d66

Hint: mm: orc; opt: speed; options: -d:release
174494 lines; 8.298s; 654.641MiB peakmem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Templates with references to same-named types across imports resolve oddly
2 participants