dlang.org
dlang.org copied to clipboard
Published
20 hours ago •
dlang
dlang
Associative array ABI is under-specified
trafficstars
Jerry Quinn (@jlquinn) reported this on 2011-11-25T14:25:09Z
Transferred from https://issues.dlang.org/show_bug.cgi?id=7008
CC List
- Andrej Mitrovic (@AndrejMitrovic)
- Walter Bright (@WalterBright)
- Martin Nowak (@MartinNowak)
Description
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.
code (@MartinNowak) commented on 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.
bugzilla (@WalterBright) commented on 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.
jlquinn commented on 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?
andrej.mitrovich (@AndrejMitrovic) commented on 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.
andrej.mitrovich (@AndrejMitrovic) commented on 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.
code (@MartinNowak) commented on 2014-04-23T13:18:09Z
BTW, I'm currently working on the library AA, but it's more work than anticipated. Mostly because getting all the details of attributes, rvalues, construction and range interfaces right is quite involved.
https://github.com/MartinNowak/dmd/tree/libraryAA
https://github.com/MartinNowak/druntime/tree/libraryAA
andrej.mitrovich (@AndrejMitrovic) commented on 2014-04-23T15:04:08Z
(In reply to Martin Nowak from comment #6)
> BTW, I'm currently working on the library AA, but it's more work than
> anticipated. Mostly because getting all the details of attributes, rvalues,
> construction and range interfaces right is quite involved.
> https://github.com/MartinNowak/dmd/tree/libraryAA
> https://github.com/MartinNowak/druntime/tree/libraryAA
Good luck with it! :>
hsteoh commented on 2014-04-23T15:34:52Z
Wow. Best wishes on that! And yes, being more complicated than anticipated is a familiar feeling w.r.t. AA's. :-)