D/Objective-C 64bit

Michel Fortin michel.fortin at michelf.ca
Wed Mar 12 12:34:30 PDT 2014


On 2014-03-12 17:53:35 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
>> On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
>> 
>>> Great. Jacob, what's your plan to take this forward? We're very
>>> interested in merging this as part of the official D compiler.
>> 
>> In theory I could create a pull request tonight. It depends on what
>> state we need the language support to be in. As I said exceptions are
>> missing on 64bit. But on the other hand when support for C++ was
>> introduced in D it had very limited support.
>> 
>> One idea is to merge the changes but wait with enabling the languages
>> changes. The test machines could run the tests with the changes enabled.
> 
> I'll defer to domain experts on this one. Please advise.

If the compiler is going to be converted to the D language (how is that 
progressing?), it'd probably be better to merge before that, otherwise 
it'll be a lot of work to port all those changes.

The first question should about the review process. This patch touches 
a lot of things, so I wonder if Walter will be confortable reviewing 
it. Should different people review different parts? Here's a comparison 
view:

DMD:  94 changed files with 8,005 additions and 48 deletions.
https://github.com/jacob-carlborg/dmd/compare/d-objc

druntime:  10 changed files with 1,263 additions and 0 deletions.
https://github.com/jacob-carlborg/druntime/compare/d-objc

Most of the changes to the compiler are inside #if DMD_OBJC/#endif 
blocks. Changes outside of those blocks shouldn't affect the semantics 
or the binary output of existing code. So I think a review could be 
done in two steps:

1. Review changes outside of those #if DMD_OBJC blocks. Those are the 
most critical changes as they'll affect the next version of the 
compiler that'll ship (I'm assuming Objective-C features won't be 
turned on until they're more usable). This includes some changes in the 
lexer, but it shouldn't affect current D code. This review could 
exclude the two files objc.h/objc.c, since the makefile ignores them 
without the D_OBJC flag.

2. Maybe review things inside of those #if DMD_OBJC blocks. Those 
things won't affect the compiler unless compiled with the D_OBJC flag, 
so it's less critical to review them. Most of them are there to 
implement Objective-C semantics so you'll need to be somewhat familiar 
with Objective-C to judge whether they're correct or not. What should 
be checked is whether an error would make them affect non-Objective-C 
constructs when they're compiled in.

We also need to know what to do about the test suite. I made a separate 
test suite for D/Objective-C since those tests can only run on OS X and 
only with the compiler compiled with Objective-C support enabled. It 
could easily be merged with the main test suite, but the tests should 
be made conditional to whether the compiler is compiled with 
Objective-C or not.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d-announce mailing list