open + preferred syms #22744
open + preferred syms #22744
Conversation
fixes nim-lang#11184, fixes nim-lang#22605, fixes nim-lang#20000
|
Why are symbols for routines special? |
|
They ideally shouldn't be super special, the main difference is that routines and now enums have alternative options, whereas other symbols can only become 1 thing. This is reflected by the compiler never accounting for symchoices with non overloadable symbols up to this point. The PR as described above is admittedly confused regarding this and for now I have changed it so the "open sym" thing only applies to new symbols generated inside generic procs, which makes it specialized for #22605 as it probably should be. The break in the delaunay package, where a symbol outside of generic proc scope beat it out due to slightly more precise parameters, shows that this design also treats scope difference as a last ditch resort in overloading rather than, say, procs in declaration scope always being prioritized as long as they match. While this is another arbitrary difference from other symbols, it's essentially preexisting and code probably depends on mixed in symbols not receiving less priority. That break specifically is caused by the implementation of #11184. This is actually independent from the rest of the PR (which itself is now multiple independent parts), but the consensus seemed to be that it should be implemented. The PR situation and previous comments shouldn't be cause for alarm, we should have something cleaner and more reasonable later. |
fixes nim-lang#22605, separated from nim-lang#22744
fixes #22605, separated from #22744 This marks symbol captures in macro calls in generic contexts as `nfOpenSym`, which means if there is a new symbol in the local instantiatied body during instantiation time, this symbol replaces the captured symbol. We have to be careful not to consider symbols outside of the instantiation body during instantiation, because this will leak symbols from the instantiation context scope rather than the original declaration scope. This is done by checking if the local context owner (maybe should be the symbol of the proc currently getting instantiated instead? not sure how to get this) is the same as or a parent owner of the owner of the replacement candidate symbol. This solution is distinct from the symchoice mechanisms which we originally assumed had to be related, if this assumption was wrong it would explain why this solution took so long to arrive at.
fixes #22605, separated from #22744 This marks symbol captures in macro calls in generic contexts as `nfOpenSym`, which means if there is a new symbol in the local instantiatied body during instantiation time, this symbol replaces the captured symbol. We have to be careful not to consider symbols outside of the instantiation body during instantiation, because this will leak symbols from the instantiation context scope rather than the original declaration scope. This is done by checking if the local context owner (maybe should be the symbol of the proc currently getting instantiated instead? not sure how to get this) is the same as or a parent owner of the owner of the replacement candidate symbol. This solution is distinct from the symchoice mechanisms which we originally assumed had to be related, if this assumption was wrong it would explain why this solution took so long to arrive at. (cherry picked from commit 9416595)
fixes #22605, separated from #22744 This marks symbol captures in macro calls in generic contexts as `nfOpenSym`, which means if there is a new symbol in the local instantiatied body during instantiation time, this symbol replaces the captured symbol. We have to be careful not to consider symbols outside of the instantiation body during instantiation, because this will leak symbols from the instantiation context scope rather than the original declaration scope. This is done by checking if the local context owner (maybe should be the symbol of the proc currently getting instantiated instead? not sure how to get this) is the same as or a parent owner of the owner of the replacement candidate symbol. This solution is distinct from the symchoice mechanisms which we originally assumed had to be related, if this assumption was wrong it would explain why this solution took so long to arrive at. (cherry picked from commit 9416595)
fixes #22605, separated from #22744 This marks symbol captures in macro calls in generic contexts as `nfOpenSym`, which means if there is a new symbol in the local instantiatied body during instantiation time, this symbol replaces the captured symbol. We have to be careful not to consider symbols outside of the instantiation body during instantiation, because this will leak symbols from the instantiation context scope rather than the original declaration scope. This is done by checking if the local context owner (maybe should be the symbol of the proc currently getting instantiated instead? not sure how to get this) is the same as or a parent owner of the owner of the replacement candidate symbol. This solution is distinct from the symchoice mechanisms which we originally assumed had to be related, if this assumption was wrong it would explain why this solution took so long to arrive at. (cherry picked from commit 9416595)
fixes #11184, fixes #22605, fixes #20000
Non-routine symbol nodes are now marked as
nfOpenSymin symbol mixin contexts, and get replaced when another symbol would have been preferred in the local sem context.Might break code that depended on old behavior, the
semOperandproblems as a consequence ofresult.typ = nilmight not be fully fixed, thedotTransformationchange might break code but I doubt it.Originally proposed as
nkOpenSymbut macros will break on a new ident node kind and it's not really a big deal if it's not respected.Edit: Also had to implement preferred syms to make routines work like they used to.
Symchoices with the first element marked as
nfPreferredSym(could be changed to put this on the symchoice node instead) treat the first element as 999 scopes deep and the rest as -1.Standalone symbol nodes can also be marked as
nfPreferredSymand should act the same as a unarynkOpenSymChoicenode, but 1. I had a lot of unexplainable errors with the compiler after just generating these (though it might work now after having improved the implementation) and 2. I'm not sure they serve the same purpose. Might try it again eventually.todo notes:
nfOpenSymnodes, currently allnkSymis ignoredmixinfor non-routine symbols should treat them asnfOpenSymnfOpenSymmight be changed significantly