The current ABI describes associative arrays as an opaque type.
However, for a debugger to work with them, it must understand the
structure. For 2 compilers to be able to generate compatible code, they must agree on the structure. Currently the ABI specifies an AA as an opaque implementation-defined type.
This means that multiple compilers will not be able to guarantee compatibility since the AA ABI is not specified. Also, debuggers must refer to the source code of the compiler druntime in order to know how to work with the contents of an AA.
Specifying C functions to manipulate the opaque pointer solves the debugger issue, but not the issue of ensuring compatibility across compilers.
Comment #1 by code — 2011-11-26T15:13:37Z
The functions are only partly helpful for a debugger.
IMHO we should switch completely to using
AssociativeArray from object.
The current situation of using it only in
certain cases is messy.
Comment #2 by bugzilla — 2011-11-26T20:48:29Z
Being an opaque pointer means that the implementation of associative arrays is entirely up to the runtime, not the compiler. The compiler should emit no dependencies on how it is implemented.
Comment #3 by jlquinn — 2011-12-11T21:32:49Z
(In reply to comment #2)
> Being an opaque pointer means that the implementation of associative arrays is
> entirely up to the runtime, not the compiler. The compiler should emit no
> dependencies on how it is implemented.
To make this work, the compiler has to have a documented interface to the AA. I feel we need a documented set of calls that will be output by the compiler, just as $ is documented as being translated to length.
At the moment, the only documentation is "read this file in druntime". It's not a guarantee of how the compiler-AA interface works. Without the guarantee another compiler cannot safely generate compatible code, and debuggers can't be guaranteed to know how to look at the contents of the AA.
Am I missing something in this request?
Comment #4 by andrej.mitrovich — 2014-04-23T11:46:47Z
If/when the hashes are replaced with a library implementation there won't be a need to emit any special debugging information, it will largely be automatic. So I think we shouldn't try to add more cruft to the compiler right now.
Comment #5 by andrej.mitrovich — 2014-04-23T11:47:12Z
(In reply to Andrej Mitrovic from comment #4)
> If/when the hashes are replaced with a library implementation there won't be
> a need to emit any special debugging information, it will largely be
> automatic. So I think we shouldn't try to add more cruft to the compiler
> right now.
Sorry, I meant to the ABI as well.