-
-
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
fixes #1027; disallow templates to use ambiguous identifiers #20631
Conversation
doesn't this root cause is by ? let candidates = searchInScopesFilterBy(c, ident, allExceptModule) #.skipAlias(n, c.config)
if candidates.len > 0:
result = candidates[0]
amb = candidates.len > 1
if amb and checkAmbiguity in flags:
errorUseQualifier(c, n.info, candidates) after latest refactoring of |
Where is it? |
|
I don't think it is related. That PR is regarding shadowing variables. |
really? so how can |
My PR 8f4bdb3 didn't change the correctness but the performance, two pieces of code are essentially identical. |
so maybe it doesn't work properly in previous ? |
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
Thanks for your hard work on this PR! Hint: mm: orc; opt: speed; options: -d:release |
Would be useful to have this backported to 1.6 -- it silently generates invalid code. |
cc @narimiran |
* test qualifiedLookUp in templates * check later * add testcase * add 4errormsg * Update tests/template/m1027a.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> * Update tests/template/m1027b.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
* Add `nkFastAsgn` into `semExpr` (#20939) * Add nkFastAsgn into case statement * Add test case * fixes #1027; disallow templates to use ambiguous identifiers (#20631) * test qualifiedLookUp in templates * check later * add testcase * add 4errormsg * Update tests/template/m1027a.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> * Update tests/template/m1027b.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> --------- Co-authored-by: Jake Leahy <jake@leahy.dev> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
…im-lang#20631) * test qualifiedLookUp in templates * check later * add testcase * add 4errormsg * Update tests/template/m1027a.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> * Update tests/template/m1027b.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
…im-lang#20631) * test qualifiedLookUp in templates * check later * add testcase * add 4errormsg * Update tests/template/m1027a.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> * Update tests/template/m1027b.nim Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
…le types in symchoices (#23997) fixes #23898, supersedes #23966 and #23990 Since #20631 ambiguous type symbols in templates are rejected outright, now we generate a symchoice for type nodes if they're ambiguous, a generalization of what was done in #22375. This is done for generics as well. Symchoices also handle type symbols better now, ensuring their type is a `typedesc` type; this probably isn't necessary for everything to work but it makes the logic more robust. Similar to #23989, we have to prepare for the fact that ambiguous type symbols behave differently than normal type symbols and either error normally or relegate to other routine symbols if the symbol is being called. Generating a symchoice emulates this behavior, `semExpr` will find the type symbol first, but since the symchoice has other symbols, it will count as an ambiguous type symbol. I know it seems spammy to carry around an ambiguity flag everywhere, but in the future when we have something like #23104 we could just always generate a symchoice, and the symchoice itself would carry the info of whether the first symbol was ambiguous. But this could harm compiler performance/memory use, it might be better to generate it only when we have to, which in the case of type symbols is only when they're ambiguous.
…le types in symchoices (#23997) fixes #23898, supersedes #23966 and #23990 Since #20631 ambiguous type symbols in templates are rejected outright, now we generate a symchoice for type nodes if they're ambiguous, a generalization of what was done in #22375. This is done for generics as well. Symchoices also handle type symbols better now, ensuring their type is a `typedesc` type; this probably isn't necessary for everything to work but it makes the logic more robust. Similar to #23989, we have to prepare for the fact that ambiguous type symbols behave differently than normal type symbols and either error normally or relegate to other routine symbols if the symbol is being called. Generating a symchoice emulates this behavior, `semExpr` will find the type symbol first, but since the symchoice has other symbols, it will count as an ambiguous type symbol. I know it seems spammy to carry around an ambiguity flag everywhere, but in the future when we have something like #23104 we could just always generate a symchoice, and the symchoice itself would carry the info of whether the first symbol was ambiguous. But this could harm compiler performance/memory use, it might be better to generate it only when we have to, which in the case of type symbols is only when they're ambiguous. (cherry picked from commit 09dcff7)
fixes #1027