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

require untyped macros/templates to match before early expansion in generics #23094

Open
wants to merge 2 commits into
base: devel
Choose a base branch
from

Conversation

metagn
Copy link
Collaborator

@metagn metagn commented Dec 18, 2023

fixes #22740

In generic procs we expand fully untyped templates/macros as long as only 1 overload is in scope, however up to this point we didn't check if this overload actually matches the call (for example if the argument numbers are different). In this PR, after picking out the single fully untyped template/macro overload, we call resolveOverloads on it to see if it matches, and don't expand it if it doesn't.

@metagn
Copy link
Collaborator Author

metagn commented Dec 23, 2023

Description added

@metagn metagn closed this Jan 6, 2024
@metagn metagn reopened this Jan 6, 2024
@metagn metagn closed this Apr 6, 2024
@metagn metagn reopened this Apr 6, 2024
@metagn metagn force-pushed the generic-template-expansion-overload branch from 8d301a2 to d54f671 Compare August 20, 2024 11:36
Araq pushed a commit that referenced this pull request Oct 7, 2024
fixes #24186 

When encountering pragma nodes in templates, if it's a language pragma,
we don't process the name, and only any values if they exist. If it's
not a language pragma, we process the full node. Previously only the
values of colon expressions were processed.

To make this simpler, `whichPragma` is patched to consider bracketed
hint/warning etc pragmas like `{.hint[HintName]: off.}` as being a
pragma of kind `wHint` rather than an invalid pragma which would have to
be checked separately. From looking at the uses of `whichPragma` this
doesn't seem like it would cause problems.

Generics have [the same
problem](https://github.com/nim-lang/Nim/blob/a27542195c9ba760d58e9d1e977313bc322a1ede/compiler/semgnrc.nim#L619)
(causing #18649), but to make it work we need to make sure the
templates/macros don't get evaluated or get evaluated correctly (i.e.
passing the proc node as the final argument), either with #23094 or by
completely disabling template/macro evaluation when processing the
pragma node, which would also cover `{.pragma.}` templates.
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.

Generics/macro interaction causes > operator to bind too early
1 participant