Migrating D front end to D - post Dconf

[Iain Buclaw]

Daniel and/or David,

We should list down in writing the issues preventing DMD, GDC, 
and LDC having a shared code base.  From what David has shown me, 
LDC will need the most work for this, but I'll list down what I 
can remember.

1. Support extern(C++) classes so can have a split C++/D 
implementation of eg: Expression and others.

2. Support representing integers and floats to a greater 
precision than what the host can natively support. In D there's 
BigInt for integral types, and there's a possibility of using 
std.numeric for floats.  For me, painless conversion between eg: 
BigInt <-> GCC's double_int is a requirement, but that is more of 
an after thought at this point in time.

3. Array ops should be moved out of the front end. The back end 
can deal with emitting the correct Libcall if required.

4. Continue building upon Target to hide target-specific things 
from the front end.  Off the top of my head I've got two to raise 
pulls for: __VENDOR__ and retrieving memalignsize for fields.

5. DMD sends messages to stdout, GDC sends to stderr.  Just a 
small implementation detail, but worth noting where 
'printf'appears, it's almost always rewritten as fprintf(stderr) 
for GDC.

6. LDC does not implement toObjFile, toCtype, toDt, toIR, 
possibly others...

7. BUILTINxxx could be moved into Target, as there is no reason 
why each back end can't support their own builtins for the 
purpose of CTFE.

8. D front end's port.h can't be used by GDC because of 
dependency  on mars.h, this could perhaps be replaced by 
std.numeric post conversion.

9. Opaque declarations of back end types defined in front end 
differ for each compiler implementation.  Eg: elem is a typedef 
to union tree_node.

10. The main function in mars.c is not used by GDC, possibly LDC 
also.  Another implementation detail but also a note to maybe 
split out errorSuplimental and others from that file.

11. The function genCfunc does not generate the arguments of the 
extern(C) symbol.

12. LDC adds extra reserved version identifiers that are not 
allowed to be declared in D code.  This could and probably should 
be merged into D front end. Don't think it would be wise to let 
back end's have the ability to add their own.  Also this list 
needs updating regardless to reflect the documented spec.

13. LDC makes some more arbitrary changes to which the reason for 
the change has been forgotten. Get on it David!  :o)

14. Reading sources asynchronously, GDC ifdefs this out.  Do we 
really need this?  I seem to recall that the speed increase is 
either negliegable or offers no benefit to compilation speed.

15. Deal with all C++ -> D conversion