summary refs log tree commit diff stats
path: root/tests/pragmas/tused.nim
diff options
context:
space:
mode:
authorZahary Karadjov <zahary@gmail.com>2017-04-16 16:11:45 +0300
committerZahary Karadjov <zahary@gmail.com>2017-04-16 16:11:45 +0300
commit13701c09579447d3c54f6a1e27ab24b89b11b9e9 (patch)
tree2c220fa47fb06706aecd06e34be44796dc13a486 /tests/pragmas/tused.nim
parent2da4a4fbe3d7ac24b05ee308d5b602a4775ed501 (diff)
downloadNim-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/pragmas/tused.nim')
0 files changed, 0 insertions, 0 deletions
10' href='#n10'>10 11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126