-
-
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
regression from 1.6/2.0.4 to version-2-0
/devel
instantiating nested generic objects generic function
#23568
Comments
version-2-0
/devel
instantiating nested generic objects generic functionversion-2-0
/devel
instantiating nested generic objects generic function
Bisecting on For 2.0.x, we can revert the backport, but ideally: we would have a proper fix in |
Maybe work around nim-lang/Nim#23568
Should be the same issue as #23310, I just realized what the issue is, semtypes calls semGenericStmt in type sections which does the genericsOpenSym behavior which it shouldn't do, we should probably only enable it for the first pass of generic procs by a flag through semGenericStmt into GenericsCtx, should be easy |
I was wrong, the culprit is this diff: d436728#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40R1028-R1031 Reverting these lines fixes the 2.0 branch but breaks devel, I'll look into fixing devel with it |
* Revert "revert to v2.0.4" This reverts commit fc3fad2. * chronos: bump Maybe work around nim-lang/Nim#23568
Mitigation for: nim-lang/Nim#23568 Signed-off-by: Jakub Sokołowski <jakub@status.im>
Mitigation for: nim-lang/Nim#23568 Signed-off-by: Jakub Sokołowski <jakub@status.im>
Mitigation for: nim-lang/Nim#23568 Signed-off-by: Jakub Sokołowski <jakub@status.im>
fixes #23568, fixes #23310 In #23091 `semFinishOperands` was changed to not be called for `mArrGet` and `mArrPut`, presumably in preparation for #23188 (not sure why it was needed in #23091, maybe they got mixed together), since the compiler handles these later and needs the first argument to not be completely "typed" since brackets can serve as explicit generic instantiations in which case the first argument would have to be an unresolved generic proc (not accepted by `finishOperand`). In this PR we just make it so `mArrGet` and `mArrPut` specifically skip calling `finishOperand` on the first argument. This way the generic arguments in the explicit instantiation get typed, but not the unresolved generic proc.
fixes #23568, fixes #23310 In #23091 `semFinishOperands` was changed to not be called for `mArrGet` and `mArrPut`, presumably in preparation for #23188 (not sure why it was needed in #23091, maybe they got mixed together), since the compiler handles these later and needs the first argument to not be completely "typed" since brackets can serve as explicit generic instantiations in which case the first argument would have to be an unresolved generic proc (not accepted by `finishOperand`). In this PR we just make it so `mArrGet` and `mArrPut` specifically skip calling `finishOperand` on the first argument. This way the generic arguments in the explicit instantiation get typed, but not the unresolved generic proc. (cherry picked from commit 09bd9d0)
Description
Nim Version
Builds:
Does not bulid:
Current Output
Expected Output
Possible Solution
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: