On 2014-03-12 17:53:35 +0000, Andrei Alexandrescu <seewebsiteforem...@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.

druntime:  10 changed files with 1,263 additions and 0 deletions.

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

Reply via email to