reset inTypeofContext in generic instantiations
#24229
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
metagn
changed the title
inTypeofContext in generic instantiationsinTypeofContext in generic instantiations [backport:2.0]
metagn
changed the title
inTypeofContext in generic instantiations [backport:2.0]inTypeofContext in generic instantiations
|
Thanks for your hard work on this PR! Hint: mm: orc; opt: speed; options: -d:release |
narimiran
pushed a commit
that referenced
this pull request
Oct 23, 2024
fixes #24228, refs #22022 As described in #24228 (comment), instantiating generic routines inside `typeof` causes all code inside to be treated as being in a typeof context, and thus preventing compile time proc folding, causing issues when code is generated for the instantiated routine. Now, instantiated generic procs are treated as never being inside a `typeof` context. This is probably an arbitrary special case and more issues with the `typeof` behavior from #22022 are likely. Ideally this behavior would be removed but it's necessary to accomodate the current [proc `declval` in the package `stew`](status-im/nim-stew#190), at least without changes to `compileTime` that would either break other code (making it not eagerly fold by default) or still require a change in stew (adding an option to disable the eager folding). Alternatively we could also make the eager folding opt-in only for generic compileTime procs so that #22022 breaks nothing whatsoever, but a universal solution would be better. Edit: Done in #24230 via experimental switch (cherry picked from commit ea9811a)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #24228, refs #22022
As described in #24228 (comment), instantiating generic routines inside
typeofcauses all code inside to be treated as being in a typeof context, and thus preventing compile time proc folding, causing issues when code is generated for the instantiated routine. Now, instantiated generic procs are treated as never being inside atypeofcontext.This is probably an arbitrary special case and more issues with the
typeofbehavior from #22022 are likely. Ideally this behavior would be removed but it's necessary to accomodate the current procdeclvalin the packagestew, at least without changes tocompileTimethat would either break other code (making it not eagerly fold by default) or still require a change in stew (adding an option to disable the eager folding).Alternatively we could also make the eager folding opt-in only for generic compileTime procs so that #22022 breaks nothing whatsoever, but a universal solution would be better. Edit: Done in #24230 via experimental switch