-
-
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
fix generic param substitution in templates #22535
Conversation
PR to fix nimPNG which relied on the bug: jangko/nimPNG#83 (merged) PR to fix nim-lang NESM (seemingly this is the one CI uses): nim-lang/NESM#1 And original NESM: xomachine/NESM#22 preemptive NESM patch descriptionNESM is really bothersome to patch, the problem is here: The |
It seems like original NESM has been inactive for a long time now, would be nice if someone could merge the patch into the nim-lang repo (nim-lang/NESM#1) for the time being. |
Sorry, the PR to NESM was not enough, made a new one for the nim-lang repo, locally tested this time: nim-lang/NESM#2 and updated the one for the original repo |
fixes nim-lang#13527, fixes nim-lang#17240, fixes nim-lang#6340, fixes nim-lang#20033, fixes nim-lang#19576, fixes nim-lang#19076
2240aa4
to
303063d
Compare
CI finally passes |
Thanks for your hard work on this PR! Hint: mm: orc; opt: speed; options: -d:release |
fixes #13527, fixes #17240, fixes #6340, fixes #20033, fixes #19576, fixes #19076
When a generic template is called, for the generic parameter in the template body to be substituted with the matching generic parameter, before evaluation the matched generic types are added to the call node as extra arguments. These nodes are
nkSym
nodes of the original generic parameter symbol, with the type of the symbol and thus the node being the matched type. This is irregular in normal code, and when the template tries to use it, it gets treated as some value with the type instead of the type itself.To prevent this, remove the type field from these nodes which will make regular code semcheck them and provide them with the appropriate type (similar to #20315). Different places in the compiler treat these symbols differently so there is no uniform computation we can do ahead of time.