On 27 January 2014 16:50, Daniel Murphy <[email protected]> wrote: > "Iain Buclaw" wrote in message > news:[email protected]... > >> I tried that once before, only to be asked "Why are you doing this?" :o) > > > I still think 'verbose' is a good idea (that switch has zero coverage in the > test suite btw). But yeah, one thing at a time. > > >> Admittedly, it had some other stuff until I gave up waiting, sent a >> pull for global.stdmsg (which got merged in) then reimplemented error, >> warning, etc... in gdc. > > > That seems fine for error/warning/etc but Loc and Global should really be > shared. Although global really shouldn't have so much crammed into it. eg > doXGeneration and debugf mean nothing to the frontend. > >
Not to mention undocumented --f --c style switches that on the surface don't even look like they do anything. But that is dmd baggage... I have toyed around with the thought of moving backend specific members into a Compiler struct which may vary across gdc, dmd, ldc... >> There are some parts that could be ported to D. But by and large, >> it's not going to be pretty. ie: There's no possible way for us to >> correctly mangle c_long in D, and there are some types in GCC that - >> depending on the host - could be typedef'd to long, long long or >> int64_t. > > > We seem to be getting away with that in dmd, as long as OSX and win64 don't > hide any more nasties. (btw do you have any idea what's wrong with pull > 3158?) > I can't see at a glance any target specific mangling for long. Only __float128 and __float80. As for long size, there's no darwin specific value for LONG_SIZE nor LONG_LONG_SIZE, so whatever you are getting, it's the same on Linux too... > Making functions extern(C) seems to be the easiest short-term solution, and > pragma(mangle) will start actually working on windows once the new C++ > mangler is in. Don't know what you are talking about, it already works on Windows... :o) I would have to seriously consider keeping or forking cppmangle once it is visual studio-afied....
