# name collision issue depending on expression order #129

Closed
opened this Issue Dec 23, 2016 · 1 comment

Projects
None yet
2 participants

### pafnucy commented Dec 23, 2016

 There is a kind of cryptic error that points to a different place, not to the one, which triggered it. It is caused by interaction of name collision and expression order. Example error message: "Compiling bug_reproduction.mzn [...]/bug_reproduction.mzn:17: MiniZinc: type error: not an array in array access" (triggered here Message above points to line with aux1 definition, which is correct. Error occurs only when we use "version B" of aux2 declaration, when it is declared before aux1. I see three issues here: with declarative nature of MiniZinc, which doesn't apply here name collision depending on expression order error message pointing in wrong direction Code for error reproduction: ``````int: z = 2; int : n = 4; set of int : IDX = 1..n; array[1..z] of IDX: g1 = [1,2]; array[1..z] of IDX: g2 = [3,4]; %% 2 versions of aux2 declaration % version B - works only if it is after aux1 array[IDX] of set of IDX : aux2 = [{g2 | g2 in IDX where aux1[g, g2]} | g in IDX]; % version A - works always (avoids g2 name collision) %array[IDX] of set of IDX : aux2 = [{g3 | g3 in IDX where aux1[g, g3]} | g in IDX]; array[IDX, IDX] of bool : aux1 = array2d(IDX, IDX, [exists([g1[i] == row /\ g2[i] == col \/ g1[i] == col /\ g2[i] == row | i in 1..z]) | row, col in IDX]); solve satisfy; ``````

### guidotack added a commit that referenced this issue Jan 13, 2017

``` Fix binding analysis during type checking, which did not handle the s… ```
`…hadowing of top-level declarations by comprehension generators correctly. Fixes #129.`
``` 947660f ```
Member

### guidotack commented Jan 13, 2017

 Thanks for the report. That was an embarrassing bug in the type checker, your code is definitely supposed to work correctly. The fix will be released with the next version of MiniZinc.