Bug 5590 – Regression(2.036) ICE(e2ir.c): when using .values on enum which is associative array

On dmd 2.051, this code import std.path; import std.range; enum aa = [5 : "hello"]; void main(string[] args) { auto a = aa.values.front; } fails to compile, giving this error: Internal error: e2ir.c 4617 With the current beta, it gives: Internal error: e2ir.c 4835 This may or may not be a duplicate of bug# 4460. I don't know enough about the compiler details to know for sure, but it does seem similar. It's definitely not quite the same circumstances though, so I'm creating a new bug just in case it is something separate.

*** Issue 5734 has been marked as a duplicate of this issue. ***

The same happens for all other AA methods (.get, .length, etc).

*** This issue has been marked as a duplicate of issue 4460 ***

Not a duplicate, but probably related.

https://github.com/D-Programming-Language/dmd/pull/685 Regression as this used to work before AssociativeArray was added to object.d. The old code is still there in TypeAArray::dotExp, and still works.

Clearly, the AA solution in D needs some re-engineering, so I'm going to have to defer fixing this for the moment.

(In reply to comment #6) > Clearly, the AA solution in D needs some re-engineering, so I'm going to have > to defer fixing this for the moment. This is also fixed by rolling back the AA implementation. https://github.com/D-Programming-Language/dmd/pull/688 https://github.com/D-Programming-Language/druntime/pull/143 If this is pulled (which I think it should be) this bug report can be closed. Pull 688 contains test cases for this bug.

Although this is a regression, it isn't recent. It last worked in 2.035 Minimal test case is: enum aa = [5 : "hello"]; void bug5520() { auto a = aa.values; }

For anyone interested in why this bug exists: When the 'aa' of 'aa.values' reaches e2ir, it is an 'ArrayLiteralExp' but is typed as the 'AssociativeArray' struct, because the type is changed in order to do member lookup. Changing the type back to an AA doesn't work, I assume because _d_assocarrayliteralTX returns a reference to an associative array and the compiler gets very confused about where it's actually stored, which seems to result in the wrong values in registers when .values is called. Or, it would if it didn't have the wrong type when it hit ::toElem. This only applies to the AA methods that only exist in the AssociativeArray struct in object.di

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/44dae0ddcbdd851f8f73d4332ecfd415a2889e72 fix Issue 5590 - Regression(2.036) ICE(e2ir.c): when using .values on enum which is associative array