diff options
author | Zahary Karadjov <zahary@gmail.com> | 2017-04-16 16:11:45 +0300 |
---|---|---|
committer | Zahary Karadjov <zahary@gmail.com> | 2017-04-16 16:11:45 +0300 |
commit | 13701c09579447d3c54f6a1e27ab24b89b11b9e9 (patch) | |
tree | 2c220fa47fb06706aecd06e34be44796dc13a486 /tests/actiontable | |
parent | 2da4a4fbe3d7ac24b05ee308d5b602a4775ed501 (diff) | |
download | Nim-13701c09579447d3c54f6a1e27ab24b89b11b9e9.tar.gz |
Restore the compilation of linalg by tweaking the complex disambiguation rules
This commit is a potentially breaking change, but the problem was that linalg was relying on a previous bug in the compiler, which was fixed in the concepts branch. With the old disambiguation rules, generic procs like: proc \`==\`[T](lhs, rhs: T) and proc \`==\`(lhs, rhs: Matrix32|Matrix64) .. were considered equal, even though it's obvious that the second one should be preferred. We never noticed this, because there was a bug in sigmatch incorrectly counting one of the params of the second proc as a non-generic match, thus giving it an edge. This commit gives some preference to tyOr and tyAnd during the complex disambiguation, which may affect overload resolution in other cases. I see this only as a temporary solution. With my upcoming work on concept refinement, I plan to provide an experimental implementation of alaternative C++-like rules for determining which proc is more specific. We can then discuss our strategy for dealing with such a breaking change.
Diffstat (limited to 'tests/actiontable')
0 files changed, 0 insertions, 0 deletions