On 2014-03-12 17:53:35 +0000, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.ca
