• via Digitalmars-d-bugs (52/52) Jun 23 2016 https://issues.dlang.org/show_bug.cgi?id=16199

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

https://issues.dlang.org/show_bug.cgi?id=16199

          Issue ID: 16199
           Summary: Looking up string-keyed AA with static char[n]
                    compiles but crashes at runtime
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: hsteoh quickfur.ath.cx

Code:
------
void main()
{
    int[string] aa1;
    int[char[]] aa2;
    int[char[4]] aa3;

    aa1["aa_1"] = 123;
    aa2["aa_1"] = 234;
    aa3["aa_1"] = 345;

    char[4] key;
    key[] = "aa_1";

    if (key in aa1)    // CRASHES
        writeln("yes");
    if (key in aa2)    // CRASHES
        writeln("yes");
    if (key in aa3)    // OK
        writeln("yes");
}
------

The reason for this is that the compiler accepts char[4] as key for aa1 and
aa2, but in _aaInX() (druntime/src/rt/aaA.d around l.404), keyti is the
TypeInfo for string (i.e. immutable(char)[]) rather than the typeinfo for
char[4] -- because that's the key type for the AA.  However, pkey is pointing
to char[4], not to a string, so the call to calcHash() will crash when it tries
to interpret char[4] as immutable(char)[].

I've a hard time deciding whether the compiler is at fault or druntime, but
decided it's the compiler's problem because druntime has no way of knowing what
the original type of pkey is, except what is passed in the keyti parameter. 
The problem is that the incoming key type is different from the AA's key type,
so druntime can't possibly do the right thing unless it takes two TypeInfo
arguments.  It's either that, or the compiler must reject using char[n] as key
to a string-keyed AA.

My recommendation is for the compiler to reject indexing a string-keyed AA with
char[n], probably with a helpful error message to slice the char[n] first.
Either that, or the compiler should implicitly emit the slicing operation for
the char[n] so that pkey is of a compatible type.

--