http://d.puremagic.com/issues/show_bug.cgi?id=7512

           Summary: Associative arrays with dstring as key do not work
                    correctly
           Product: D
           Version: D2
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: hsteoh@quickfur.ath.cx


--- Comment #0 from hsteoh@quickfur.ath.cx 2012-02-15 11:56:43 PST ---
Test case:

void main() {
        int[dstring] map = ["abc"d: 123];
        foreach (key, val; map) {
                assert(map[key] == val); // throws RangeError ?!
        }
}


Changing dstring to string fixes the problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #1 from hsteoh@quickfur.ath.cx 2012-02-27 10:29:15 PST ---
Update: wstring keys fail the foreach test too:

int[wstring] map = ["abc"w: 1, "def"w: 2];
foreach (key, val; map) {
    assert((key in map) !is null); // throws AssertError
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #2 from hsteoh@quickfur.ath.cx 2012-02-27 12:42:04 PST ---
OK, I've narrowed down this bug to using an AA literal for when the key is a non-string array. For some strange reason, the AA literal *appears* to correctly initialize the AA, as far as foreach can tell:

// CODE:
const int[] key1 = [1,2,3];
const int[] key2 = [1,2,4];
int[int[]] a5 = [
    key1 : 3,
    key2 : 4
];
foreach (key, val; a5) {
    writefln("%s -> %s", key, val);
}

// OUTPUT:
[1, 2, 3] -> 3
[1, 2, 4] -> 4

Seems to be correct, however:

// CODE:
foreach (key, val; a5) {
    assert(a5[key]==val);
}

// OUTPUT:
core.exception.AssertError@aatest(15): Assertion failure

This is the failing case. However, if we *don't* use an AA literal:

// CODE:
const int[] key1 = [1,2,3];
const int[] key2 = [1,2,4];
int[int[]] a5;
a5[key1] = 3;
a5[key2] = 4;
foreach (key, val; a5) {
    assert(a5[key]==val);
}


Then there is no assertion failure.

Conclusion: something screwy is going on when an AA literal is used. The AA appears to be initialized correctly, and foreach appears to return the correct key/value pairs, *but* attempting to do lookups with the keys fails for some unknown reason.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #3 from hsteoh@quickfur.ath.cx 2012-02-27 13:57:09 PST ---
Even more weirdness:

int[int[]] a7;
const int[] key1 = [1,3,5];
const int[] key2 = [2,4,6];
a7[key1] = 135;
a7[key2] = 246;

int[int[]] a8 = [key1: 135, key2: 246];
assert(a7 == a8); // OK!
assert(a7[key1] == 135); // OK!
assert(a8[key1] == 135); // throws RangeError (?!)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #4 from hsteoh@quickfur.ath.cx 2012-02-27 14:01:53 PST ---
Direct proof that something really weird is going on:

const int[] key1 = [1,3,5];
const int[] key2 = [2,4,6];
int[int[]] a8 = [ key1: 135, key2: 246 ];
a8[key1] = 135; // you'd think this should have no effect
foreach (key, val; a8) {
    // But you'd be wrong...
    writeln("%s -> %s", key, val);
}

// OUTPUT:
[2, 4, 6] -> 246
[1, 3, 5] -> 135
[1, 3, 5] -> 135

(Note the duplicated identical key->value pair.)

So the key/value pair initialized by the AA literal is somehow "different" from the key/value pair assigned by "a8[key]=value;".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #5 from hsteoh@quickfur.ath.cx 2012-02-27 17:39:10 PST ---
Found cause of problem:

const int[] key = [1,2,3,4];
int[int[]] map1 = [ key: 1234 ];

// map1's internal hashtable has keyti pointing to typeid(const(int)[])

int[int[]] map2;
map2[key] = 1234;

// map2's internal hashtable has keyti pointing to typeid(int[])

This causes 'key' to map to a different hash value in map1 than in map2. So far, no real problem yet. However, this:

map1[key] = 1234;

computes the hash value of 'key' using typeid(int[]).getHash(), NOT
typeid(const(int)[]).getHash(), causing a duplicate entry to appear in map1.
That is, the hash value of 'key' in the above line is exactly the same as the
hash value of key in "map2[key] = 1234". In fact, it seems that AA.get() and
AA[...] always uses the non-const typeinfo to compute the hash value, so it
will never find the keys created by the AA literal. The only time the entries
in the AA literal are actually visible is via foreach.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #6 from hsteoh@quickfur.ath.cx 2012-02-27 20:12:51 PST ---
Apparently AA.get() and AA[key] *always* computes the hash value based on the unqualified type, whereas AA literals use the const type which computes a different hash value. For example:

int[dstring] map = ["abc"d: 1];
assert(map["abc"d]==1); // throws range error
assert(("abc"d in map) !is null); // assertion fails
map["abc"d] = 1; // creates duplicated entry (foreach finds "abc"d:1 twice)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512



--- Comment #7 from hsteoh@quickfur.ath.cx 2012-02-29 08:02:19 PST ---
Fixed in latest git: https://github.com/D-Programming-Language/druntime/commit/96bc813e2a87a05da36b55274c44efd4e704417b

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7512


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


--- Comment #8 from hsteoh@quickfur.ath.cx 2012-02-29 10:19:39 PST ---
Hmm, apparently Walter's hash fix wasn't enough. Something else is still going wrong with the hash value somewhere.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------